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

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

[David Mc Kenna]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

Sorry here are the files

>Thanks for the reply,
>
>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 ) .
>
>Any help is appreciated,
>Dave Mc Kenna
>
>
>>On Fri, 8 Mar 2002, David Mc Kenna wrote:
>>
>>> When I compile a program without specifying -save-temps with GCC I can view

>
>>> the code in 4 formats under Insight,i.e. Source,Assembly, Mixed and SRC
+
>ASM.
>>> But when I use the -save-temps switch with GCC I am unable to view the source

>
>>> code as mixed, it appears identical to assembly.
>>
>>I tried this using GNUPro 00r1 gcc, a special internal x86 compiler, and
>>stock gcc from RH7.0 against both CVS Insight and 5.1.1 Insight. I'd say
>>that this looks like a compiler problem.
>>
>>I don't have 3.0.x installed anywhere, can you send me an executable (or
>>its debug info)? What target?
>>
>>Keith
>>
>>
>>
>Sun Tzu once wrote......
>The supreme act of war is to subdue the enemy without fighting....
>--
>http://www.iol.ie
>
>
Sun Tzu once wrote......
The supreme act of war is to subdue the enemy without fighting....
--
http://www.iol.ie

[-- Attachment #2: test.zip --]
[-- Type: application/x-zip-compressed, Size: 251818 bytes --]

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

[David Mc Kenna]

Thanks for the reply,

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

Any help is appreciated,
Dave Mc Kenna


>On Fri, 8 Mar 2002, David Mc Kenna wrote:
>
>> When I compile a program without specifying -save-temps with GCC I can view

>> the code in 4 formats under Insight,i.e. Source,Assembly, Mixed and SRC +
ASM.
>> But when I use the -save-temps switch with GCC I am unable to view the source

>> code as mixed, it appears identical to assembly.
>
>I tried this using GNUPro 00r1 gcc, a special internal x86 compiler, and
>stock gcc from RH7.0 against both CVS Insight and 5.1.1 Insight. I'd say
>that this looks like a compiler problem.
>
>I don't have 3.0.x installed anywhere, can you send me an executable (or
>its debug info)? What target?
>
>Keith
>
>
>
Sun Tzu once wrote......
The supreme act of war is to subdue the enemy without fighting....
--
http://www.iol.ie

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

[Keith Seitz]

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

Code display question ( RE GCC - save-temps )

[David Mc Kenna]

Hi all,

Just a quick question with relation to both GCC and GDB.

When I compile a program without specifying -save-temps with GCC I can view
the code in 4 formats under Insight,i.e. Source,Assembly, Mixed and SRC + ASM.
But when I use the -save-temps switch with GCC I am unable to view the source
code as mixed, it appears identical to assembly.

The test program I am using is a simple "hello world" program. GCC is v3.0.4
under cygwin. Insight/GDB is v5.1.1 under cygwin.

Any help is appreciated,
Dave McKenna


--
http://www.iol.ie

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

[Keith Seitz]

On Fri, 8 Mar 2002, David Mc Kenna wrote:

> When I compile a program without specifying -save-temps with GCC I can view
> the code in 4 formats under Insight,i.e. Source,Assembly, Mixed and SRC + ASM.
> But when I use the -save-temps switch with GCC I am unable to view the source
> code as mixed, it appears identical to assembly.

I tried this using GNUPro 00r1 gcc, a special internal x86 compiler, and
stock gcc from RH7.0 against both CVS Insight and 5.1.1 Insight. I'd say
that this looks like a compiler problem.

I don't have 3.0.x installed anywhere, can you send me an executable (or
its debug info)? What target?

Keith