This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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:

  + "/" 
  + 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"));
              if (do_wide || strlen ((char *) directory_table[0]) < 76)
                printf (_("CU: %s/%s:\n"), directory_table[0],
                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; }
cat >> main.c <<EOF
#include <f1.c>
int main (void) { return 0; }
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

f1.c                                           1           0x8048394

f1.c                                           1           0x8048397

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?

- 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.

Carlos O'Donell
Mentor Graphics / CodeSourcery
+1 (613) 963 1026

Attachment: dw2-decodedline.diff
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]