arm-elf-gdb "Cannot find bounds of current function"

arm-elf-gdb "Cannot find bounds of current function"

[Bill Gatliff]

Guys:


I'm trying to track down a problem here that's got me stumped.  I've 
tested with gdb-5.2.1, 5.3, and 6.0, all with the same results.

I'm using one of my own gdb stubs to debug on an arm-elf target.  I'm 
using the remote serial protocol and pristine gdb sources.

I can load and stepi instructions just fine, but when I try to step a 
source line, gdb reports an error, "Cannot find bounds of current 
function".  I can list and disassemble functions just fine, and the 
application is an ELF file that was compiled with -g.

The same program steps fine on the simulator, and I've verified that 
there are no differences between the sp, lr, pc, or other register 
values between the two environments.  RDI on another target works fine 
as well.

I'm using gcc-3.2.1, binutils-2.13.1.

Any suggestions?  I'm pulling my hair out on this one...


b.g.

-- 
Bill Gatliff
Embedded GNU development and training services.
bgat@billgatliff.com

Re: arm-elf-gdb "Cannot find bounds of current function"

[Bill Gatliff]

Guys:


Here's a little bit more on this.  When running the arm-elf-gdb under 
gdb (thank goodness for the 'set prompt' command!), I have found that 
when I do a "step", arm-elf-gdb ends up in find_pc_sect_section().  The 
interesting part is this:

find_pc_sect_section (pc=0x0, section=0x30821820) at 
../../gdb-5.3/gdb/objfiles.c:955
[snip]
...
959       ALL_OBJSECTIONS (objfile, s)
(gdb) step
960         if ((section == 0 || section == s->the_bfd_section) &&  
s->addr <= pc && pc < s->endaddr)
(gdb) print *s
$5 = {addr = 0x20188000, endaddr = 0x2018801c, offset = 0x0,
  the_bfd_section = 0x9398f4c, objfile = 0x9393ff8, ovly_mapped = 0x0}
(gdb) print pc
$6 = 0x30821820
(gdb)

In other words, the obj_section structure's first (?) section starts at 
address 0x20188000, and is 0x1c bytes long.  The PC received from the 
target, however, is 0x30821820, which is 0x20188230 reversed.  The 
lookup is failing because the address is endian-swapped.

Funny thing is, arm-elf-gdb appears to be able to show me source lines 
just fine when I breakpoint them, I just can't step them after that.  
Almost as if it's using two different numbers for the PC (one in the 
correct endian sense, the other not).  My stub sends back a T message 
after a breakpoint, and I see gdb asking with 'g' shortly thereafter, 
I'm wondering if that's somehow related...

Ideas now anyone?


b.g.


Bill Gatliff wrote:

> Guys:
>
>
> I'm trying to track down a problem here that's got me stumped.  I've 
> tested with gdb-5.2.1, 5.3, and 6.0, all with the same results.
>
> I'm using one of my own gdb stubs to debug on an arm-elf target.  I'm 
> using the remote serial protocol and pristine gdb sources.
>
> I can load and stepi instructions just fine, but when I try to step a 
> source line, gdb reports an error, "Cannot find bounds of current 
> function".  I can list and disassemble functions just fine, and the 
> application is an ELF file that was compiled with -g.
>
> The same program steps fine on the simulator, and I've verified that 
> there are no differences between the sp, lr, pc, or other register 
> values between the two environments.  RDI on another target works fine 
> as well.
>
> I'm using gcc-3.2.1, binutils-2.13.1.
>
> Any suggestions?  I'm pulling my hair out on this one...
>
>
> b.g.
>

-- 
Bill Gatliff
Do you do embedded GNU?  I do!
bgat@billgatliff.com

Re: arm-elf-gdb "Cannot find bounds of current function"

[Bill Gatliff]

Guys:


*blush* *blush* *blush*

On ARM, my stub's 'T' response was returning register values with a 
different endian ordering from that returned in the 'g' packet.  I 
turned off 'T' altogether, and now things appear to be working fine.  
Buggy 'T' implementation, apparently.

For the one or two of you out there using gdbstubs, heed the comment in 
gdb.c:gdb_handle_exception(), turn off the 'T' response!


b.g.



Bill Gatliff wrote:

> Guys:
>
>
> Here's a little bit more on this.  When running the arm-elf-gdb under 
> gdb (thank goodness for the 'set prompt' command!), I have found that 
> when I do a "step", arm-elf-gdb ends up in find_pc_sect_section().  
> The interesting part is this:
>
> find_pc_sect_section (pc=0x0, section=0x30821820) at 
> ../../gdb-5.3/gdb/objfiles.c:955
> [snip]
> ...
> 959       ALL_OBJSECTIONS (objfile, s)
> (gdb) step
> 960         if ((section == 0 || section == s->the_bfd_section) &&  
> s->addr <= pc && pc < s->endaddr)
> (gdb) print *s
> $5 = {addr = 0x20188000, endaddr = 0x2018801c, offset = 0x0,
>  the_bfd_section = 0x9398f4c, objfile = 0x9393ff8, ovly_mapped = 0x0}
> (gdb) print pc
> $6 = 0x30821820
> (gdb)
>
> In other words, the obj_section structure's first (?) section starts 
> at address 0x20188000, and is 0x1c bytes long.  The PC received from 
> the target, however, is 0x30821820, which is 0x20188230 reversed.  The 
> lookup is failing because the address is endian-swapped.
>
> Funny thing is, arm-elf-gdb appears to be able to show me source lines 
> just fine when I breakpoint them, I just can't step them after that.  
> Almost as if it's using two different numbers for the PC (one in the 
> correct endian sense, the other not).  My stub sends back a T message 
> after a breakpoint, and I see gdb asking with 'g' shortly thereafter, 
> I'm wondering if that's somehow related...
>
> Ideas now anyone?
>
>
> b.g.
>
>
> Bill Gatliff wrote:
>
>> Guys:
>>
>>
>> I'm trying to track down a problem here that's got me stumped.  I've 
>> tested with gdb-5.2.1, 5.3, and 6.0, all with the same results.
>>
>> I'm using one of my own gdb stubs to debug on an arm-elf target.  I'm 
>> using the remote serial protocol and pristine gdb sources.
>>
>> I can load and stepi instructions just fine, but when I try to step a 
>> source line, gdb reports an error, "Cannot find bounds of current 
>> function".  I can list and disassemble functions just fine, and the 
>> application is an ELF file that was compiled with -g.
>>
>> The same program steps fine on the simulator, and I've verified that 
>> there are no differences between the sp, lr, pc, or other register 
>> values between the two environments.  RDI on another target works 
>> fine as well.
>>
>> I'm using gcc-3.2.1, binutils-2.13.1.
>>
>> Any suggestions?  I'm pulling my hair out on this one...
>>
>>
>> b.g.
>>
>

-- 
Bill Gatliff
Affordable GNU and Linux training and consulting services.
bgat@billgatliff.com