Breakpoint function address

Breakpoint function address

[Spen]

Hi,

I have just updated to using gdb 6.6 from 6.5 (actually using insight).
Part of my startup script is to set a breakpoint @ main: thb main

This has been fine under 6.5 but seems to have broken under 6.6 (also tried
cvs head).
The problem occurs if I link with the gc-sections option, removing this
option the breakpoints are set correctly.

With gc-secions
thb main will set the breakpoint @ 0x00000004
gdb 6.6 (gdb head does not) reports the following when loading the file:
misplaced first line number at 0x48 for 'VICITCmd'

Without gc-sections
thb main set to 0x0000028c as expected.

print main produces (with/without gc-sections).
$1 = {int (void)} 0x27c <main>

My target is remote arm-elf (using openocd) running under cygwin.
The same problem occurs if building under gcc 3.4.6 or 4.2.

Any help would be greatly appreciated.

Cheers
Spen

Re: Breakpoint function address

[Daniel Jacobowitz]

On Tue, Aug 21, 2007 at 03:01:34PM +0100, Spen wrote:
> With gc-secions
> thb main will set the breakpoint @ 0x00000004
> gdb 6.6 (gdb head does not) reports the following when loading the file:
> misplaced first line number at 0x48 for 'VICITCmd'

It sounds like your linker has broken the debug info.  We will need a
test binary to be sure.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Breakpoint function address

[Spen]

> It sounds like your linker has broken the debug info.  We 
> will need a test binary to be sure.
> 
> --
> Daniel Jacobowitz
> CodeSourcery
> 

Thanks for the reply,

Have also have tried with gcc 3.4.6, 4.2 and 4.2 (arm-eabi) - the same
results. So I thought the problem was related to the symbols being read by
gdb, not being produced by the linker.

I am guessing this list does not allow attachments, can I send a test binary
to you?

Cheers
Spen

Re: Breakpoint function address

[Daniel Jacobowitz]

On Tue, Aug 21, 2007 at 03:27:10PM +0100, Spen wrote:
> I am guessing this list does not allow attachments, can I send a test binary
> to you?

Sure.  I will try to look at it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Breakpoint function address

[Daniel Jacobowitz]

On Tue, Aug 21, 2007 at 03:01:34PM +0100, Spen wrote:
> Hi,
> 
> I have just updated to using gdb 6.6 from 6.5 (actually using insight).
> Part of my startup script is to set a breakpoint @ main: thb main
> 
> This has been fine under 6.5 but seems to have broken under 6.6 (also tried
> cvs head).
> The problem occurs if I link with the gc-sections option, removing this
> option the breakpoints are set correctly.

I tried your binaries with an arm-none-eabi GDB from 2007-02-26, since
that was what I had handy.  It worked just fine.  Are you sure you
sent me the right binaries?

-- 
Daniel Jacobowitz
CodeSourcery

RE: Breakpoint function address

[Spen]

> I tried your binaries with an arm-none-eabi GDB from 
> 2007-02-26, since that was what I had handy.  It worked just 
> fine.  Are you sure you sent me the right binaries?
> 
> --
> Daniel Jacobowitz
> CodeSourcery
> 

Very strange, been doing a few more tests:
GNU gdb (CodeSourcery Sourcery G++ Lite 2007q1-10) 6.6.50.20070320-cvs
Crashes when trying to load problem elf file

GNU gdb (Sourcery G++ 4.1-40) 6.6.50.20061124-cvs
Works on both files and breakpoint set correctly.

If target sim is used then all versions of gdb work ok.
Changing to target remote are when the problems occur - I have been using
gdb 6.5 for a while now and never had any problems.

Cheers
Spen

Re: Breakpoint function address

[Daniel Jacobowitz]

On Wed, Aug 22, 2007 at 10:50:22AM +0100, Spen wrote:
> Very strange, been doing a few more tests:
> GNU gdb (CodeSourcery Sourcery G++ Lite 2007q1-10) 6.6.50.20070320-cvs
> Crashes when trying to load problem elf file
> 
> GNU gdb (Sourcery G++ 4.1-40) 6.6.50.20061124-cvs
> Works on both files and breakpoint set correctly.
> 
> If target sim is used then all versions of gdb work ok.
> Changing to target remote are when the problems occur - I have been using
> gdb 6.5 for a while now and never had any problems.

Well, obviously I can't try it with target remote; I don't have your
target.  Could you post a complete bad session using "set debug remote 1"
before connecting to the target?

-- 
Daniel Jacobowitz
CodeSourcery

RE: Breakpoint function address

[Spen]

> Well, obviously I can't try it with target remote; I don't 
> have your target.  Could you post a complete bad session 
> using "set debug remote 1"
> before connecting to the target?

Sorry for data overload but here are various logs.

GNU gdb 6.6.50.20070813-cvs - working elf
w $qSupported#37
r +$#00
w ++$Hc-1#09
r +$#00
w +$qC#b4
r +$#00
w +$qOffsets#4b
r +$#00
w +$?#3f
r +$S02#b5
w +$Hg0#df
r +$#00
w +$g#67
r
+$ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffff000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000d3000060#8d
w +$m0,4#fd
r +$18f09fe5#38
w +$qSymbol::#5b
r +$#00
w +
c 
c b main
c 
c s
w $Z0,28c,4#e3
r +$OK#9a
w +$vCont?#49
r +$#00
w +$Hc0#db
r +$#00
w +$s#73
r +$T05#b9
w +$g#67
r
+$ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffff000a0004ffffffff440100000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000d3000060#1b
w +$m144,4#66
r +$f0f09fe5#65
w +$mfffffffe,4#fc
r +$000018f0#bf
w +$mffffffff,4#fd
r +$0018f09f#fe
w +$m9ff017f8,4#08
r +$E05#aa
w +
c quit
w $k#6b
r +
End of log

GNU gdb 6.6.50.20070813-cvs - failed elf
w $qSupported#37
r +$#00
w ++$Hc-1#09
r +$#00
w +$qC#b4
r +$#00
w +$qOffsets#4b
r +$#00
w +$?#3f
r +$S02#b5
w +$Hg0#df
r +$#00
w +$g#67
r
+$ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffff000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000d3000060#8d
w +$m0,4#fd
r +$18f09fe5#38
w +$qSymbol::#5b
r +$#00
w +
c 
c b main
c 
c s
w $Z0,4,4#4a
r +$OK#9a
w +$vCont?#49
r +$#00
w +$Hc0#db
r +$#00
w +$s#73
r +$T05#b9
w +$g#67
r
+$ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffff000a0004ffffffff440100000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000d3000060#1b
w +$m144,4#66
r +$f0f09fe5#65
w +$mfffffffb,4#f9
r +$00000000#80
w +$m0,4#fd
r +$18f09fe5#38
w +$mfffffff7,4#ce
r +$00000000#80
w +$z0,4,4#6a
r +$OK#9a
w +
c 
c quit
w $k#6b
r +
End of log

GNU gdb (Sourcery G++ 4.1-40) 6.6.50.20061124-cvs - works on both files
w $qSupported#37
r +$#00
w ++$Hc-1#09
r +$#00
w +$qC#b4
r +$#00
w +$qOffsets#4b
r +$#00
w +$?#3f
r +$S02#b5
w +$Hg0#df
r +$#00
w +$g#67
r
+$ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffff000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000d3000060#8d
w +$m0,4#fd
r +$18f09fe5#38
w +$qSymbol::#5b
r +$#00
w +
c 
c b main
w $m27c,4#99
r +$00482de9#00
w +
C 
c s
w $Z0,27c,4#e2
r +$OK#9a
w +$vCont?#49
r +$#00
w +$Hc0#db
r +$#00
w +$s#73
r +$T05#b9
w +$g#67
r
+$ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffff000a0004ffffffff440100000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000d3000060#1b
w +$m144,4#66
r +$f0f09fe5#65
w +$mfffffffb,4#f9
r +$00000000#80
w +$m0,4#fd
r +$18f09fe5#38
w +$mfffffff7,4#ce
r +$00000000#80
w +$s#73
r +$T05#b9
w +$g#67
r
+$ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffff000a0004ffffffff480100000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000d3000060#1f
w +$m148,4#6a
r +$0000a0e1#e7
w +$z0,27c,4#02
r +$OK#9a
w +
c 
c quit
w $k#6b
r +
End of log

GNU gdb (CodeSourcery Sourcery G++ Lite 2007q1-10) 6.6.50.20070320-cvs -
failed elf
w $qSupported#37
r +$#00
w ++$Hc-1#09
r +$#00
w +$qC#b4
r +$#00
w +$qOffsets#4b
r +$#00
w +$?#3f
r +
Then crashes with a Access Violation - 0xc0000005

Cheers
Spen

Re: Breakpoint function address

[Daniel Jacobowitz]

On Thu, Aug 23, 2007 at 09:48:21AM +0100, Spen wrote:
> GNU gdb 6.6.50.20070813-cvs - failed elf

I compiled current CVS for arm-elf.  I connected to a remote
gdbserver - not quite the same but as close as I can manage.
I repeated your steps and the breakpoint went to the right
location.

Then I tried using gdbreplay on your log file.  That time I got
the bad breakpoint.

Your ELF file shows:

 <1><196f>: Abbrev Number: 19 (DW_TAG_subprogram)
  <1970>     DW_AT_sibling     : <1a0f>
  <1974>     DW_AT_external    : 1
  <1975>     DW_AT_name        : (indirect string, offset: 0x8f7): VIC_Config
  <1979>     DW_AT_decl_file   : 1
  <197a>     DW_AT_decl_line   : 724
  <197c>     DW_AT_prototyped  : 1
  <197d>     DW_AT_low_pc      : 0
  <1981>     DW_AT_high_pc     : 0x3f0
  <1985>     DW_AT_frame_base  : 1 byte block: 5b       (DW_OP_reg11)

That's interesting because that function does not exist in your file
anywhere.  You've only got debug info for it.  I assume that it was
discarded by --gc-sections.  This should hopefully tip you off:

#0  VIC_Config (VIC_Source=65535, VIC_LineMode=4294967295, VIC_Priority=255 '�')

Probably not where you expected to be when you connected to your target.

Try building a CVS snapshot of binutils or using the 2.18 prerelease
snapshot from two weeks ago, and relinking.  I recently changed the
way the linker behaves when updating debug info for discarded
functions.  It will now set the high PC of the function to 0, so we
will never decide it is current.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Breakpoint function address

[Spen]

> 
> Try building a CVS snapshot of binutils or using the 2.18 
> prerelease snapshot from two weeks ago, and relinking.  I 
> recently changed the way the linker behaves when updating 
> debug info for discarded functions.  It will now set the high 
> PC of the function to 0, so we will never decide it is current.
> 
> --
> Daniel Jacobowitz
> CodeSourcery
> 

Daniel,

Just tried binutils-2.18.50 snapshot and it has fixed the problem,
breakpoints now correctly set.

Many thanks once again for all your help, very much appreciated.

Spen