Re: [RFA]corelow.c: Add tid to add_to_thread_list

[Pedro Alves <pedro@codesourcery.com>]

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