This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM, registers, "frame 0", where's the PC?


Hi,

i found out by testing that the first time i stop the target
and read out its registers, the value of R15 is used in the
message "Program stopped at 0x12345678".

When i type in GDB:
(gdb) info frame
Stack level 0, frame at 0x1000:
 pc = 0x12345678; saved pc 0x20203a8
 (FRAMELESS), called by frame at 0x1000
 Arglist at 0x1000, args: 
 Locals at 0x1000, Previous frame's sp in sp

Could these problems be related to the structures on the
stack?  When i set R15 to 0x0000 the first time i
read out the registers, i get the message "Program stopped
at 0x00000000".  What can i do to tell GDB to use the
real value in R15?

I appended a log file of a session, all requests and answers
are in there.  Is any of the answers not correct?

Could this be related to the startup code of the test program?
I attached it to this mail.


It would be great if anybody had a hint for me.


Best regards,
Torsten.


> Hi,
>
> i received a hint by mail to send ALL registers from the
> GDB remote protocol server back to arm-unknown-elf-insight.
>
> I now do that but it i still get this unwanted behaviour:
>
> I can download a program, start it, stop it, read registers
> (the correct values are shown, as i see in the debug output
> of my debug server).  The values make sense, R15 is exactly
> where i expect it to be.
>
> But when i stop the program, "insight" tells me that it
> stopped at 0x01002048.  That's nowhere in my program
> and not what's shown in R15.
>
> In the GDB console, "info registers" shows the same values
> as in "insight".  Especially "p/x $pc" says 0x02020070
> what makes sense and is correct.
>
> In "info gdb" i read:
>
>    Normally, register values are relative to the selected stack frame
> (*note Selecting a frame: Selection.).  This means that you get the
> value that the register would contain if all stack frames farther in
> were exited and their saved registers restored.  In order to see the
> true contents of hardware registers, you must select the innermost
> frame (with `frame 0').
>
> When i type "frame 0", gdb says:
> gdb) frame 0
> #0  0x01002048 in ?? ()
>
> This seems to be related to the problem.  I have to admit i don't
> understand that.  Why can't GDB say where it stopped, it has the
> correct value for R15.  Also, inbetween the stop ("\x03") and the
> reading of the registers ("g") there is no other request from
> GDB.  What info is missing?
>
>
> Thanks for any hints,
> Torsten.

Attachment: log.txt
Description: Text document

Attachment: start.s
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]