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]

Fw: GDB-6.2


----- Original Message -----
From: Krzysztof Błaszkowski
To: gdb@sources.redhat.com
Sent: Friday, August 06, 2004 3:21 PM
Subject: GDB-6.2


Hi all,

    At first I would like to say that this is a good job. I am really
impressed. I've been developing jtag adapter for arm7tdmi architecture with
linux (uClinux) task support and a tcp RSP protocol interface for a some
period of time so I have seen the 5.3 and 6.0 versions. The new one (6.2)
relocates properly the static local variables from .data and .bss sections.
The older versions used a pointers which were 4 byte less than the real one.
I have tested the "add-symbol-file" command which is very essential to me.
Now I can see also a thread list when frame pointer is NULL (a r11) so there
is no annoying "No frame" message. Also "bt" works perfectly. I can select
any kernel (or userland) thread and see its backtrace.

    I have observed that the 6.2 gdb is able to select a thread for
execution only for first time. I mean a first "thread _number_". The
succesive "thread"  commands changes registers obviously but when I issue a
"c" and system stops at breakpoint in different task then I try to execute
step by step other task (the current - I issue "i thr" and "thr" with new
ID) than the selected one for first time, the gdb takes incorrect address
for breakpoint. It takes an address from the first selected task not the
current one I would like to execute. Any ideas ?
I have to quit gdb at present and run it again to change the task for
execution.

I have got a question regarding to the task with pid number 0. Why is that
task skipped by gdb ? Should my adapter add a 1e6 to the pid of this task ?

Can someone explain me the uniqueness of the init task? (after it has
replaced itself with an init from root file system). I have discovered that
it does not store pt_regs as other userland tasks so it must use a
context_save_struct as other kernel tasks I guess. The init task has also a
mm. I used a mm pointer to distinguish a userland task and a kernel task.
That way fails for an init task. Is there a better way ?

Best regards,
Krzysztof Blaszkowski

Systemy mikroprocesorowe Krzysztof Blaszkowski
Santocka 44
71-071 Szczecin, Poland

http://www.sysmikro.com.pl


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