This is the mail archive of the gdb-patches@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]

thread ptids when debugging from core file (x86-linux)


Hello,

We recently noticed that Ada task switching doesn't work when debugging
a program using a core file. This is on x86-linux.

ada-tasks.c is just a module similar to thread*.c. It shows the list of
Ada tasks (high-level equivalent of C threads), and allows a user to
switch from one task to the other. Ada tasks are usually mapped
one-on-one on threads, so task switching is implemented by using
the thread layer: Given a certain task to switch to, we deduce from
some data stored in the GNAT runtime memory (+ the inferior ptid)
the PTID of the associated thread, and then ask the thread layer
to switch to that PTID.

Unfortunately, that doesn't work when debugging from a core file,
because the PTID of the threads are not the same as when debugging
live. According to corelow.c:add_to_thread_list(), the thread PTID
is a degenerated {pid, 0, 0} where pid is just the number in the section
name where the thread has been dumped (ie section ".reg/1234" => thread
ptid = {1234, 0, 0}).

This breaks the mapping that we computed in the ada-tasks layer,
and thus causes the task switch to fail, because ada-tasks asks
thread to switch to a thread it doesn't know about.

I was wondering whether I could be able to dig the original thread
PTIDs back from the data stored in the core file. Would anybody know?
Is there some sort of documentation on how this core file is created
and what information it contains?  How are the number in the .reg/n
sections generated? Are they PID+n where PID is the inferior PID and
n the thread number?

If I can't find the original PTIDs, I really don't know how I am going
to be able to restore the mapping between the Ada tasks and the
underlying threads. Does anybody have some ideas of how this could be
done? We don't have much information in the GNAT runtime. It's all
stored in the Ada Task Control Block (ATCB) and basically our only
link is that thread ID.

Thanks,
-- 
Joel


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