[PATCH] Fix objdump -WL output. (resent)

[Carlos O'Donell <carlos_odonell at mentor dot com>]

Nick,

The output of objdump -WL is incorrect for some input,
the following explains why, and provides a patch to fix it.

The line number program header contains two tables, the 
include_directories table and file_names table; these tables
should be used when constructing the full path to a file per
the DWARF standard.

The file_names table entries index the include_directories
entries, and given the index the full path to a file can
be constructed as:

  include_directories[file_names[n]->directory_index] 
  + "/" 
  + file_names[n]->name

If directory_index is "0" then that represents the current
directory e.g. "." (which is not part of the include_directories
table to save space).

In binutils/dwarf.c (display_debug_lines_decoded) line 2956
~~~
          /* Print the Compilation Unit's name and a header.  */
          if (directory_table == NULL)
            {
              printf (_("CU: %s:\n"), file_table[0].name);
              printf (_("File name                            Line number    Starting address\n"));
            }
          else
            {
              if (do_wide || strlen ((char *) directory_table[0]) < 76)
                printf (_("CU: %s/%s:\n"), directory_table[0],
                        file_table[0].name);
              else
                printf ("%s:\n", file_table[0].name);

              printf (_("File name                            Line number    Starting address\n"));
            }
~~~

This code assumes that because directory_table exists
that the first CU's file_table entry must belong to the first 
directory_table entry.

While this is true for simple cases it does not follow
the standard and fails for the following example:
~~~
mkdir a
cat >> a/f1.c <<EOF
int f1 (void) { return 0; }
EOF
cat >> main.c <<EOF
#include <f1.c>
int main (void) { return 0; }
EOF
gcc -g3 -O0 -Ia -o main main.c
objdump -WL main

main:     file format elf32-i386

Decoded dump of debug contents of section .debug_line:

CU: a/main.c:
File name                            Line number    Starting address

a/f1.c:
f1.c                                           1           0x8048394

f1.c                                           1           0x8048397

./main.c:[++]
main.c                                         2           0x804839e
main.c                                         2           0x80483a1
~~~
In this case the directory table exists and contains
"a", which is erroneously used as the directory entry for
file_table[0] and -WL prints "CU: a/main.c:" which is incorrect,
it should read "CU: ./main.c:" as is correctly printed 
when processing the line number program.

The following patch fixes this by looking up exactly which 
directory_table entry should be used for file_table[0].

The patch also has a generic regression test that is distilled
from the above example. You will note that I use `nop' to keep 
the function size from being zero because a zero sized function 
will not generate line number information. Every architecture 
I've checked has a `nop' mnemonic that can be used to force 
line number generation. Do you see any problem with this?

What about targets that don't support DWARF? Do I need to 
condition the the new objdump.exp test in some way to prevent
it from running on targets that don't have DWARF support?

Tested on i686-pc-linux-gnu, and arm-none-eabi with no regressions.

OK to checkin?

Notes: 
- I have a follow-up patch that fixes the 80-column output
issue that I pointed out last week.
- Paul Woegerer and I have copyright assignment through Mentor to 
submit patches to binutils.

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos@codesourcery.com
+1 (613) 963 1026

Attachment: dw2-decodedline.diff
Description: Text document