This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Don't use thread_db on corefiles
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