Re: Thread names in gdb7.7(using info threads command)

Re: Thread names in gdb7.7(using info threads command)

[Sreejith M M]

Hello,

This is my first email to the mailing list. Apologize if this is not
the right place to send this kind of request.

I am trying to see thread names in gdb. Thread names are  defined with

  prctl (PR_SET_NAME, "Mythread2", 0, 0, 0); //MyThread2 is my thread name

inside my thread.

My problem is.


I have an application which spawns 2 threads and one of the thread
will execute an illegal memory access and exit with 'segmentation
fault' and then generated a core file.


 I am able to see the thread name from gdb7.7 which comes pre
installed with my ubuntu 14.04 when I   run the application from gdb(
I put a break point just before the segmentation fault and saw the
thread names with info thread command).. But I am not able to see

the thread name after the application generates a core dump when I
load core file using core-file command.

Thanks,
Sreejith


I would like to understand how I can see the thread names when from
the core file generated by the application

Re: Thread names in gdb7.7(using info threads command)

[Pedro Alves]

On 07/17/2014 06:07 PM, Sreejith M M wrote:

> I am trying to see thread names in gdb. Thread names are  defined with
> 
>   prctl (PR_SET_NAME, "Mythread2", 0, 0, 0); //MyThread2 is my thread name
> 

...

> the thread name after the application generates a core dump when I
> load core file using core-file command.

> I would like to understand how I can see the thread names when from
> the core file generated by the application

Unfortunately, I don't think this information is stored anywhere in the
core dump.

-- 
Thanks,
Pedro Alves

Re: Thread names in gdb7.7(using info threads command)

[Pedro Alves]

On 08/19/2014 04:43 PM, Pedro Alves wrote:
> On 07/17/2014 06:07 PM, Sreejith M M wrote:
> 
>> I am trying to see thread names in gdb. Thread names are  defined with
>>
>>   prctl (PR_SET_NAME, "Mythread2", 0, 0, 0); //MyThread2 is my thread name
>>
> 
> ...
> 
>> the thread name after the application generates a core dump when I
>> load core file using core-file command.
> 
>> I would like to understand how I can see the thread names when from
>> the core file generated by the application
> 
> Unfortunately, I don't think this information is stored anywhere in the
> core dump.

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.

-- 
Thanks,
Pedro Alves

Re: Thread names in gdb7.7(using info threads command)

[Sreejith M M]

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. 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.


Thanks,
Sreejith

On Tue, Aug 19, 2014 at 9:20 PM, Pedro Alves <palves@redhat.com> wrote:
> On 08/19/2014 04:43 PM, Pedro Alves wrote:
>> On 07/17/2014 06:07 PM, Sreejith M M wrote:
>>
>>> I am trying to see thread names in gdb. Thread names are  defined with
>>>
>>>   prctl (PR_SET_NAME, "Mythread2", 0, 0, 0); //MyThread2 is my thread name
>>>
>>
>> ...
>>
>>> the thread name after the application generates a core dump when I
>>> load core file using core-file command.
>>
>>> I would like to understand how I can see the thread names when from
>>> the core file generated by the application
>>
>> Unfortunately, I don't think this information is stored anywhere in the
>> core dump.
>
> 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.
>
> --
> Thanks,
> Pedro Alves

Re: Thread names in gdb7.7(using info threads command)

[Pedro Alves]

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.

Thanks,
Pedro Alves