From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Hui Zhu <teawater@gmail.com>
Subject: Re: [RFA]corelow.c: Add tid to add_to_thread_list
Date: Fri, 06 Aug 2010 09:57:00 -0000 [thread overview]
Message-ID: <201008061057.03037.pedro@codesourcery.com> (raw)
In-Reply-To: <AANLkTimiQres0-zY_An1bbi5yG9DfNzCc0_jtT2u0P5_@mail.gmail.com>
On Friday 06 August 2010 03:55:51, Hui Zhu wrote:
> 2010-08-06 Hui Zhu <teawater@gmail.com>
>
> * corelow.c(add_to_thread_list): Add tid.
>
> ---
> corelow.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> --- a/corelow.c
> +++ b/corelow.c
> @@ -244,7 +244,7 @@ add_to_thread_list (bfd *abfd, asection
> {
> ptid_t ptid;
> int core_tid;
> - int pid, lwpid;
> + int pid, lwpid, tid;
> asection *reg_sect = (asection *) reg_sect_arg;
>
> if (strncmp (bfd_section_name (abfd, asect), ".reg/", 5) != 0)
> @@ -278,7 +278,13 @@ add_to_thread_list (bfd *abfd, asection
> if (current_inferior ()->pid == 0)
> inferior_appeared (current_inferior (), pid);
>
> - ptid = ptid_build (pid, lwpid, 0);
> + tid = 0;
> + do
> + {
> + ptid = ptid_build (pid, lwpid, tid);
> + tid ++;
> + }
> + while (find_thread_ptid (ptid));
>
> add_thread (ptid);
Sorry, no. It's not a good idea to have the corelow target
using both the lwpid and the tid fields. It leaves no room for a
thread_stratum target on top to use. Going by what someone
said on the other thread:
> The goal was always that something could post process the output of
> the kernel crashdump and create something that is gdb compatible. It
> looks to me like it would take just a moment to strip out all of the
> idle threads.
What are exactly these "threads" with no PID? How useful is it for gdb
to expose them as threads? Are these the idle threads, one per core, not
associated with any process? Are we talking about a regular process core
dump, or some other core dump? From the comment quoted above, it appears
that it would be expected that something just stripped out / ignored
these "threads"/notes. Say, a post processor tool, or bfd, or gdb.
BTW, with this particular patch, you've only gotten past this one
problem, but, you'll be tripping on others. For example, all register
accesses for lwpid=XXX,tid=0, lwpid=XXX,tid=1, lwpid=XXX,tid=2, etc.,
will be going to the same .reg/XXX section.
--
Pedro Alves
next prev parent reply other threads:[~2010-08-06 9:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-03 8:49 Hui Zhu
2010-08-05 18:44 ` Tom Tromey
2010-08-06 2:56 ` Hui Zhu
2010-08-06 9:57 ` Pedro Alves [this message]
2010-08-06 16:48 ` Hui Zhu
2010-08-06 17:18 ` Pedro Alves
2010-08-06 20:06 ` Pedro Alves
2010-08-06 20:50 ` Maciej W. Rozycki
2010-08-09 2:28 ` Hui Zhu
2010-08-09 14:48 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201008061057.03037.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=teawater@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox