This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA]corelow.c: Add tid to add_to_thread_list
On Friday 06 August 2010 17:47:53, Hui Zhu wrote:
> The root cause about this issue is the idle thread's pid is 0.
I'm still interested in answers to the questions I wrote before.
Reading the thread again, I understand this a kernel dump core.
Am I correct? I've never loaded one in gdb, hence my questions.
From your early objdump output,
Sections:
Idx Name Size VMA LMA File off Algn
0 note0 00000a48 0000000000000000 0000000000000000 00000238 2**0
CONTENTS, READONLY
1 .reg/0 000000d8 0000000000000000 0000000000000000 000002bc 2**2
CONTENTS
2 .reg 000000d8 0000000000000000 0000000000000000 000002bc 2**2
CONTENTS
3 .reg/2719 000000d8 0000000000000000 0000000000000000 00000420 2**2
CONTENTS
4 .reg/0 000000d8 0000000000000000 0000000000000000 00000584 2**2
CONTENTS
5 .reg/0 000000d8 0000000000000000 0000000000000000 000006e8 2**2
there's always one thread per core, never more. Is that correct? Is there
any indication in the core notes that would allow us to identify this core
as a kernel core, not an application core? IMO, since we're debugging at
the kernel level, we'd instead use that info to teach bfd info building the
.reg sections as, say:
0 note0 00000a48 0000000000000000 0000000000000000 00000238 2**0
CONTENTS, READONLY
1 .reg/1 000000d8 0000000000000000 0000000000000000 000002bc 2**2
CONTENTS
2 .reg 000000d8 0000000000000000 0000000000000000 000002bc 2**2
CONTENTS
3 .reg/2 000000d8 0000000000000000 0000000000000000 00000420 2**2
CONTENTS
4 .reg/3 000000d8 0000000000000000 0000000000000000 00000584 2**2
CONTENTS
5 .reg/4 000000d8 0000000000000000 0000000000000000 000006e8 2**2
that is, identify the cores, not the process the core happened to be
running.
> If
> more than one cpu is in idle and each cpu will be a thread in core
> file, we got a core file that have some thread ptid is same.
> For now, gdb cannot handle it:
> struct thread_info *
> add_thread_silent (ptid_t ptid)
> {
If this function hit an internal error in this scenario, then
it has a bug. I think Maciej wrote a patch to fix it in our
internal tree. I'll try to look for it. Note that with this
fixed, gdb would still discard all idle threads but one,
and, when accessing the registers of the one that stays, we'd
be accessing the wrong .reg section.
--
Pedro Alves