[PATCH] Fix objdump -WL output. (resent)
Carlos O'Donell
carlos_odonell@mentor.com
Sat Oct 1 20:43:00 GMT 2011
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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dw2-decodedline.diff
URL: <https://sourceware.org/pipermail/binutils/attachments/20111001/db746f52/attachment.ksh>
More information about the Binutils
mailing list