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

[Kevin Buettner <kevinb@redhat.com>]

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