Re: [RFA] Don't use thread_db on corefiles

Kevin Buettner
2001-12-17T05:32:18Z

On Dec 16, 8:56pm, Daniel Jacobowitz wrote:

> My instinct was "there is support in corefile-specific code for
> handling threads. It works just fine; use it." It's been there since
> 1993. Does it have any current consumers? I think it must, since
> Kevin touched it in May and mentioned some sort of regressions.

I explained this in:

http://sources.redhat.com/ml/gdb-patches/2001-04/msg00279.html

Here's the relevant bit:

In addition to the renaming of identifiers, I also performed a type
analysis and introduced calls to PIDGET (which is an existing macro
which extracts a pid from a combined pid/tid) in cases where a pid
was needed and calls to pid_to_ptid in cases where a pid needed to
be converted into one of the combined objects. I ran into two
problems with the current representation:

[problem one elided]

- Second, I saw some regressions on Solaris due to the fact that
corelow.c was storing some corefile thread identifiers
in inferior_pid. On Solaris 8, more than 16 bits are needed to
represent these identifiers. For this case, I introduced some
#ifdefs in corelow.c which use inferior_ptid (renamed from
inferior_pid) "as is" without any masking. I plan to eliminate
these ifdefs as part of phase 3. (Or I could even do it as a
phase 4, if desired.)

[I'm wondering if there's a better place (than my patch email) to
describe this sort of thing. Our current ChangeLog style doesn't
really accomodate it. Also, I think adding something like the above
as a comment to the code would needlessly clutter it. Is there anywhere
else it could go?]

Anyway, I think the above also addresses your question about current
consumers.

Kevin