gdb & arm

gdb & arm

[Quality Quorum]

Hi,

I run into annoying problem with arm gdb, it is still there
in gdb-20011002: if set a break point into function, then function
parameters will be printed incorrectly when break point is hit.

It seems that breakpoint is hit before the function prologue is complete,
gdb uses symbol description applicable to the body of the function, and
before function prologue is done symbols simply do not match
their descriptions.

Everything gets back to normal once you reach the first source line
in the function.

It is not terminal problem but quite annoying one.

I am wondering are there any way to fix it. I suppose it should
be trivially simple in case of arm with apcs-32 ?

Can anybody help ?

Thanks,

Aleksey

Re: gdb & arm

[Keith Seitz]

On Thu, 4 Oct 2001, Quality Quorum wrote:

> I run into annoying problem with arm gdb, it is still there
> in gdb-20011002: if set a break point into function, then function
> parameters will be printed incorrectly when break point is hit.
>
> It seems that breakpoint is hit before the function prologue is complete,
> gdb uses symbol description applicable to the body of the function, and
> before function prologue is done symbols simply do not match
> their descriptions.

I've seen this problem recently, too. I'll assume that you've turned on
debugging info when compiling.

Can you do me a favor, set a breakpoint in arm_skip_prologue before
setting a breakpoint in arm-xxx-gdb? Does it use the debug info to figure
out where the prologue ends? Or does it try to figure it out manually?

I've seen cases where the compiler has output wrong debug info and caused
gdb to go to manual prologue decoding, which isn't very sophisticated. I
have a patch to beef it up a little, but it is just a hack: nothing that I
would submit to the external list.

I could send it to you if you were daring enough to try it. :-)
Keith

Re: gdb & arm

[Quality Quorum]

On Thu, 4 Oct 2001, Keith Seitz wrote:

> On Thu, 4 Oct 2001, Quality Quorum wrote:
>
> > I run into annoying problem with arm gdb, it is still there
> > in gdb-20011002: if set a break point into function, then function
> > parameters will be printed incorrectly when break point is hit.
> >
> > It seems that breakpoint is hit before the function prologue is complete,
> > gdb uses symbol description applicable to the body of the function, and
> > before function prologue is done symbols simply do not match
> > their descriptions.
>
> I've seen this problem recently, too. I'll assume that you've turned on
> debugging info when compiling.
>
> Can you do me a favor, set a breakpoint in arm_skip_prologue before
> setting a breakpoint in arm-xxx-gdb? Does it use the debug info to figure
> out where the prologue ends? Or does it try to figure it out manually?

It call to arm_skip_prologue call find_pc_partial_function and
it succeeds.

My function start looks like following

    mov ip, sp
    stmdb !sp, { ...}
    sub fp, ip, #4
(*) <start moving data from apcs registers to locations
     described in symbol tables>


(*) - breakpoint goes here.



>
> I've seen cases where the compiler has output wrong debug info and caused
> gdb to go to manual prologue decoding, which isn't very sophisticated. I
> have a patch to beef it up a little, but it is just a hack: nothing that I
> would submit to the external list.
>
> I could send it to you if you were daring enough to try it. :-)
> Keith
>
>

It seems to me that the problem is a little bit different,
we have to check that if we had stopped at this place we have
to simply use our knowledge of apcs calling convention instead
of symbol table.

Thanks,

Aleksey

Re: gdb & arm

[Keith Seitz]

On Thu, 4 Oct 2001, Quality Quorum wrote:

> It call to arm_skip_prologue call find_pc_partial_function and
> it succeeds.

So:

  if (find_pc_partial_function (pc, NULL, &func_addr, &func_end))
    {
      sal = find_pc_line (func_addr, 0);
      if ((sal.line != 0) && (sal.end < func_end))
        return sal.end;
    }

find_pc_partial_function and find_pc_line succeed, but sal.end=func_end,
right? This is the problem I had. Line table problems from gcc was my
determination.


> My function start looks like following
>
>     mov ip, sp
>     stmdb !sp, { ...}
>     sub fp, ip, #4
> (*) <start moving data from apcs registers to locations
>      described in symbol tables>
>
>
> (*) - breakpoint goes here.

The prologues I was looking were exactly like this. I think we may be
seeing the same problem. What does readelf say for the line info?

Keith

Re: gdb & arm

[Quality Quorum]

On Thu, 4 Oct 2001, Keith Seitz wrote:

> On Thu, 4 Oct 2001, Quality Quorum wrote:
>
> > It call to arm_skip_prologue call find_pc_partial_function and
> > it succeeds.
>
> So:
>
>   if (find_pc_partial_function (pc, NULL, &func_addr, &func_end))
>     {
>       sal = find_pc_line (func_addr, 0);
>       if ((sal.line != 0) && (sal.end < func_end))
>         return sal.end;
>     }
>
> find_pc_partial_function and find_pc_line succeed, but sal.end=func_end,
> right? This is the problem I had. Line table problems from gcc was my
> determination.

???? I do not understand you, sal.end contains a value pointed by (*)
below. I suppose it is a correct behavior.
>
>
> > My function start looks like following
> >
> >     mov ip, sp
> >     stmdb !sp, { ...}
> >     sub fp, ip, #4
> > (*) <start moving data from apcs registers to locations
> >      described in symbol tables>
> >
> >
> > (*) - breakpoint goes here.
>
> The prologues I was looking were exactly like this. I think we may be
> seeing the same problem. What does readelf say for the line info?

I am working with arm-aout and arm-aout-readelf  was built but it does
not like file format. Can use objdump for the purpose ?

> Keith

Thanks,

Aleksey

Re: gdb & arm

[Keith Seitz]

On Thu, 4 Oct 2001, Quality Quorum wrote:

> > So:
> >
> >   if (find_pc_partial_function (pc, NULL, &func_addr, &func_end))
> >     {
> >       sal = find_pc_line (func_addr, 0);
> >       if ((sal.line != 0) && (sal.end < func_end))
> >         return sal.end;
> >     }
> >
> > find_pc_partial_function and find_pc_line succeed, but sal.end=func_end,
> > right? This is the problem I had. Line table problems from gcc was my
> > determination.
>
> ???? I do not understand you, sal.end contains a value pointed by (*)
> below. I suppose it is a correct behavior.

What does "p/x sal.end" and "p/x func_end" give?

> I am working with arm-aout and arm-aout-readelf  was built but it does
> not like file format. Can use objdump for the purpose ?
>

Yes, even better! If you're using stabs, by all means use objdump: it's
much easier (for me, at least) to parse objdump than dwarf2 lineinfo.

Keith

Re: gdb & arm

[Quality Quorum]

On Thu, 4 Oct 2001, Keith Seitz wrote:

> On Thu, 4 Oct 2001, Quality Quorum wrote:
>
> > > So:
> > >
> > >   if (find_pc_partial_function (pc, NULL, &func_addr, &func_end))
> > >     {
> > >       sal = find_pc_line (func_addr, 0);
> > >       if ((sal.line != 0) && (sal.end < func_end))
> > >         return sal.end;
> > >     }
> > >
> > > find_pc_partial_function and find_pc_line succeed, but sal.end=func_end,
> > > right? This is the problem I had. Line table problems from gcc was my
> > > determination.
> >
> > ???? I do not understand you, sal.end contains a value pointed by (*)
> > below. I suppose it is a correct behavior.
>
> What does "p/x sal.end" and "p/x func_end" give?

sal.end is 0x20394, func_end is 0x203cc

>
> > I am working with arm-aout and arm-aout-readelf was built but it
> does > not like file format. Can use objdump for the purpose ? >
>
> Yes, even better! If you're using stabs, by all means use objdump: it's
> much easier (for me, at least) to parse objdump than dwarf2 lineinfo.

Below are various dumps related to function in question

Disassembly:

00020384 <_i2oDmaStart>:
   20384:       e1a0c00d        mov     ip, sp
   20388:       e92dd800        stmdb   sp!, {fp, ip, lr, pc}
   2038c:       e24cb004        sub     fp, ip, #4      ; 0x4
   20390:       e24dd018        sub     sp, sp, #24     ; 0x18
   20394:       e50b0010        str     r0, [fp, -#16]
   20398:       e50b1014        str     r1, [fp, -#20]
   2039c:       e50b2018        str     r2, [fp, -#24]
   203a0:       e50b301c        str     r3, [fp, -#28]
   203a4:       e51b301c        ldr     r3, [fp, -#28]
   203a8:       e58d3000        str     r3, [sp]
   203ac:       e59b3004        ldr     r3, [fp, #4]
   203b0:       e58d3004        str     r3, [sp, #4]
   203b4:       e3a00001        mov     r0, #1  ; 0x1
   203b8:       e51b1010        ldr     r1, [fp, -#16]
   203bc:       e51b2014        ldr     r2, [fp, -#20]
   203c0:       e51b3018        ldr     r3, [fp, -#24]
   203c4:       eb0008b4        bl      2269c <_nicArmDmaStart>
   203c8:       e91ba800        ldmdb   fp, {fp, sp, pc}


Symtab dump:

00020394      d  .text 015e 00 44
000203a4      d  .text 015f 00 44
0002269c g       .text 0000 00 05 _nicArmDmaStart
000203c8      d  .text 0160 00 44
00020384      d  .text 015e 00 24 i2oDmaStart:F19
fffffff0      d  *ABS* 015c 00 a0 pciAddr:p4
ffffffec      d  *ABS* 015c 00 a0 localAddr:p4
ffffffe8      d  *ABS* 015d 00 a0 byteCount:p4
ffffffe4      d  *ABS* 015d 00 a0 cback:p190
00000004      d  *ABS* 015d 00 a0 arg:p70

Source with line numbers:

348: void i2oDmaStart(UINT32 pciAddr, UINT32 localAddr,
349:                  UINT32 byteCount, i2oDmaCallback cback, void *arg)
350: {
351:    nicArmDmaStart(DMA_TOPCI, pciAddr, localAddr, byteCount, cback, arg);
352: }



So, by time gdb stops in 0x20394 values from registers are not copied
to the frame yet.

>
> Keith
>
>

Thanks,

Aleksey

Re: gdb & arm

[Fernando Nasser]

Keith Seitz wrote:
> 
> On Thu, 4 Oct 2001, Quality Quorum wrote:
> 
> > It call to arm_skip_prologue call find_pc_partial_function and
> > it succeeds.
> 
> So:
> 
>   if (find_pc_partial_function (pc, NULL, &func_addr, &func_end))
>     {
>       sal = find_pc_line (func_addr, 0);
>       if ((sal.line != 0) && (sal.end < func_end))
>         return sal.end;
>     }
> 
> find_pc_partial_function and find_pc_line succeed, but sal.end=func_end,
> right? This is the problem I had. Line table problems from gcc was my
> determination.
> 

Yes, I have seen something like this.  The reason was some bogus
optimization
that would remove duplicate line number info from the debug information
and
gdb needs the two first ones to determine the end of the prologue.

Try changing the debug format with the -g option of gcc.  If I am not
mistaken
this would only affect one of the formats (I can't remember if it was
stabs or
dwarf2).

P.S.: The fix is in the compiler/linker land --GDB does not get enough
info so
there is nothing much that can be done there except forcing a prologue
scan
(which suffers from constant compiler generation changes and some
insufficient
information in some cases).

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9