This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb & arm
- To: Keith Seitz <keiths at cygnus dot com>
- Subject: Re: gdb & arm
- From: Quality Quorum <qqi at world dot std dot com>
- Date: Thu, 4 Oct 2001 19:08:26 -0400
- cc: <gdb at sources dot redhat 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