Discussion:
Thread names in gdb7.7(using info threads command)
(too old to reply)
Sreejith M M
2014-07-17 17:07:48 UTC
Permalink
Raw Message
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
Pedro Alves
2014-08-19 15:43:21 UTC
Permalink
Raw Message
Post by Sreejith M M
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
...
Post by Sreejith M M
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
Pedro Alves
2014-08-19 15:50:42 UTC
Permalink
Raw Message
Post by Pedro Alves
Post by Sreejith M M
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
...
Post by Sreejith M M
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
Sreejith M M
2014-08-20 06:08:06 UTC
Permalink
Raw Message
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
Post by Pedro Alves
Post by Pedro Alves
Post by Sreejith M M
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
...
Post by Sreejith M M
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
Pedro Alves
2014-08-20 09:06:12 UTC
Permalink
Raw Message
Post by 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.
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.
Post by Sreejith M M
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.
Post by Sreejith M M
Post by Pedro Alves
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

Loading...