Line Table Problems

Line Table Problems

[Andrew Burgess]

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

Hi,

I have an assembler file bar.s (attached) that I can compile (on x86),
   $ gcc -g3 -Wa,-gdwarf-2 -Wa,-g -o bar.x bar.s
   $ gcc --version
   gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
   $ as --version
   GNU assembler (GNU Binutils for Ubuntu) 2.20.1-system.20100303

Now I debug bar.x using current gdb head,

   $ cat cmds.gdb
   set height 0
   set trace-commands 1
   start
   set $foo_s = &foo
   set $foo_e = &foo + 0x20
   p/x &foo
   interpreter-exec mi "-data-disassemble -s $foo_s -e $foo_e -- 3"
   $ gdb -x cmds.gdb bar.x

The interesting lines of output from gdb are,
   +p/x &foo
   $1 = 0x80483b4

and,
 
^done,asm_insns=[src_and_asm_line={line="11",file="bar.orig.s",line_asm_insn=[{address="0x080483b9",func-name="foo",offset="5",opcodes="90",inst="nop"}]},src_and_asm_line={line="12",file="bar.orig.s",line_asm_insn=[]},src_and_asm_line={line="13",file="bar.orig.s",line_asm_insn=[{address="0x080483ba",func-name="foo",offset="6",opcodes="90",inst="nop"}]},src_and_asm_line={line="14",file="bar.orig.s",line_asm_insn=[]},src_and_asm_line={line="15",file="bar.orig.s",line_asm_insn=[]},src_and_asm_line={line="16",file="bar.orig.s",line_asm_insn=[]},src_and_asm_line={line="17",file="bar.orig.s",line_asm_insn=[]},src_and_asm_line={line="18",file="bar.orig.s",line_asm_insn=[]},src_and_asm_line={line="19",file="bar.orig.s",line_asm_insn=[{address="0x080483bb",func-name="main",offset="0",opcodes="90",inst="nop"}]}]


In the disassembly view the first address covered is 0x080483b9 despite 
the function foo starting at 0x80483b4.

I believe this is caused by the line table that covers foo attributing 
some of the code to a different file. When we ask for a disassembly of a 
particular address I believe the process goes something like,

   address -> funciton -> symtab -> line-table -> line-table-entry

But gdb only stores line table entries relating to the current symtab 
with each symtabs line table, as a result if in the DWARF a function is 
described as coming from two different files we will split the line 
number information between two different symtabs, only one of which we 
will find when performing a disassembly, and so we'll only every get 
part of the source code information.

My question then is, am I doing something wrong, what could I do 
differently to get gdb to give me the full file/line-number information, 
or does this look like a gdb bug?


Thanks,
Andrew

[-- Attachment #2: bar.s --]
[-- Type: text/plain, Size: 940 bytes --]

        .file 1 "bar.orig.s"
        .file 2 "bar.inc.s"

        .loc 1 1
        .text

        .loc 1 3
        # This is just a comment.

        .loc 2 1
        # Setup a macro that includes .loc directives.
        .loc 2 2        
        .macro  prologue
        .loc 2 3
        nop
        .loc 2 4
        nop
        .loc 2 5
        nop
        .loc 2 6
        nop
        .loc 2 7
        nop
        .loc 2 8        
        .endm

        .loc 1 6
        .global foo
        .loc 1 7        
        .type foo,@function
        .loc 1 8        
foo:
        .loc 1 9
        prologue

        .loc 1 11
        nop

        .loc 1 13
        nop
        .loc 1 14        
        .size foo,.-foo

        .loc 1 16        
        .global main
        .loc 1 17        
        .type main,@function
        .loc 1 18        
main:
        .loc 1 19        
        nop
        .loc 1 20        
        .size main,.-main

Re: Line Table Problems

[Jan Kratochvil]

On Wed, 05 Oct 2011 14:25:54 +0200, Andrew Burgess wrote:
> My question then is, am I doing something wrong, what could I do
> differently to get gdb to give me the full file/line-number
> information, or does this look like a gdb bug?

I am not posting a fix, just that you guessed the reason right and it is due
to that mode `3' you use there:
  if (mode & 0x1)
    disasm_flags |= DISASSEMBLY_SOURCE;

which is the same as /m for the CLI `disassemble' command which is filed as:
	[Bug gdb/11833] New: disassemble/m should be PC-driven, not source line driven
	http://sourceware.org/bugzilla/show_bug.cgi?id=11833


Thanks,
Jan