This is the mail archive of the mailing list for the GDB 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]

Line Table Problems


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



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: bar.s
Description: Text document

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