Re: gdb & arm

[Quality Quorum <qqi at world dot std dot com>]

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