This is the mail archive of the 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: Thread names in gdb7.7(using info threads command)

On 08/20/2014 07:08 AM, Sreejith M M wrote:
> Thanks Pedro for the reply.
> To make things clearer, I get the thread names when I do live
> debugging( Run the image from gdb and crash)
> I am not getting the information only when I independently run the
> image and take the core dump to be analyzed in gdb.
> What my question is , whether coredump will have the required
> information or not. 

Unfortunately, the Linux core dump format is underdocumented.  You'll
have to web search and read sources to get more familiar with it, sorry.
Start by looking at /usr/include/linux/elfcore.h, and looking at bfd's and
gdb's sources for the structures defined there.  Look around for info on
core notes (NT_PRPSINFO, etc.).  The elfutils sources would also be another
good source.

As to whether the info is there or not, I'm not sure; you'll have to
experiment.  Try using "eu-readelf -n" on the core, and see if the
thread name is there somewhere.  I think it might end up in PRPSINFO/fname,
but I'm not 100% sure, and my time budget doesn't allow for
investigating further at this point, sorry.

> Why I am asking this again is because I did not
> understand how a gdb patch (as you have mentioned) can read the right
> data from core dump. Could you please explain a bit more?
> PS: I am newbie to gdb and dont understand the code quite well. If you
> can give some pointers, I will try to implement the patch if it is
> useful.

See the target_thread_name calls in gdb/thread.c.  When debugging
against a live target, that ends up calling into
linux-nat.c:linux_nat_thread_name, which extracts the thread name
out of /proc/PID/task/TID/comm.  When debugging a core dump, that
target_thread_name call ends up in the corelow.c target_ops
implementation instead.  You'll need to add a to_thread_name hook to
core_ops, that then calls info bfd to get the thread name somehow,
assuming the info is indeed there.

>> Or maybe it is, in NT_PRPSINFO / prpsinfo->pr_fname ?  In that case,
>> all we'd need is a gdb patch to make use of it.  See the
>> target_thread_name target method.  We'd need an implementation in
>> corelow.c.

Pedro Alves

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