This is the mail archive of the insight@sources.redhat.com mailing list for the Insight 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]

Re: Code display question ( RE GCC - save-temps )


On Tue, 19 Mar 2002, David Mc Kenna wrote:

> The target is for arm-elf.
> Included is the c source that I am using and 2 bzipped elf files, one with -save-temps
> string ( testwst.elf ) and one without ( testwost.elf ) .

Ok, I believe that this is probably a compiler bug, but I've never gotten
a clear explanation of what the proper behavior of gcc should be with
save-temps. I can only claim what I think the proper behavior should be,
from a user's perspective.

Here's a rundown of the problem. When asking Insight to display mixed mode
source and assembly, what we do is ask gdb for the symtab which contains
the given PC of the function.

Gdb returns to us the symtab for "test.i". However, this symtab does NOT
contain any linetable, so we default to displaying assembly. (This is also
why the source window defaults to showing assembly when you start up
Insight on testwst.elf.)

I believe that the bug we are seeing is that the compiler is outputting
information for an intermediate file into the debug info, and that is
messing things up for us.

If you run readelf on your executable, you'll find that both "test.c" (the
real source file) and "test.i" (some compiler intermediate file) are
mentioned. IMO, this is wrong.

"test.i" is considered to be the real source file, according to the debug
information:

 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_stmt_list   : 0
     DW_AT_high_pc     : 0x8104 33028
     DW_AT_low_pc      : 0x80c4 32964
     DW_AT_name        : test.i
     DW_AT_comp_dir    : /c/TEst/temp2
     DW_AT_producer    : GNU C 3.0.4
     DW_AT_language    : 1      (ANSI C)

"test.c" is not mentioned until the linetable information is output:

 The File Name Table:
  Entry Dir     Time    Size    Name
  1     0       0       0       test.i
  2     2       0       0       sys/reent.h
  3     1       0       0       test.c
  4     2       0       0       sys/config.h
  5     3       0       0       stddef.h
  6     3       0       0       stdarg.h
  7     2       0       0       sys/_types.h
  8     2       0       0       stdio.h

 Line Number Statements:
  Extended opcode 2: set Address to 0x80c4
  Set File Name to entry 3 in the File Name Table
  Special opcode 13: advance Address by 0 to 0x80c4 and Line by 3 to 4
  Extended opcode 2: set Address to 0x80ce
  Special opcode 13: advance Address by 0 to 0x80ce and Line by 3 to 7
  Extended opcode 2: set Address to 0x80de
  Special opcode 12: advance Address by 0 to 0x80de and Line by 2 to 9
  Extended opcode 2: set Address to 0x80ea
  Special opcode 8: advance Address by 0 to 0x80ea and Line by -2 to 7
  Extended opcode 2: set Address to 0x80f6
  Special opcode 14: advance Address by 0 to 0x80f6 and Line by 4 to 11
  Extended opcode 2: set Address to 0x80f8
  Special opcode 11: advance Address by 0 to 0x80f8 and Line by 1 to 12
  Extended opcode 2: set Address to 0x8104
  Extended opcode 1: End of Sequence

As you can see, the line table is associated with entry 3 (test.c), and
test.i has no linetable.

Now the unfortunate part is that this doesn't seem to manifest itself as a
bug in command-line gdb. I haven't investigated why this is so, but I did
find one small thing that shows this bug: If you type "info func main",
gdb will tell you that main came from "test.i", which is incorrect.

I tried this on a GNUPro release, and indeed, as I suspected, "test.i" is
never mentioned in the dwarf2 debug info. Only test.c exists, which is why
it works for me and not for you.

Keith



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