This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 0/3] Fix issues with writing Linux core PRSTATUS note on MIPS o32, n32 and n64 into core file
- From: "Maciej W. Rozycki" <macro at mips dot com>
- To: Pedro Alves <palves at redhat dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: Djordje Todorovic <djordje dot todorovic at rt-rk dot com>, <binutils at sourceware dot org>, <gdb-patches at sourceware dot org>, "nemanja dot popov at rt-rk dot com" <nemanja dot popov at rt-rk dot com>, <petar dot jovanovic at rt-rk dot com>, "Ananthakrishna Sowda (asowda)" <asowda at cisco dot com>, Nikola Prica <nikola dot prica at rt-rk dot com>, <libc-alpha at sourceware dot org>
- Date: Wed, 8 Nov 2017 18:39:57 +0000
- Subject: Re: [PATCH 0/3] Fix issues with writing Linux core PRSTATUS note on MIPS o32, n32 and n64 into core file
- Authentication-results: sourceware.org; auth=none
- References: <74618d56-fa31-4cfe-329f-6a9078bac92b@rt-rk.com> <alpine.DEB.2.00.1710171449200.3886@tp.orcam.me.uk> <724f0bc9-6744-a915-d19d-77db7e9ce514@rt-rk.com> <alpine.DEB.2.00.1710252126220.3886@tp.orcam.me.uk> <64ad38a4-b8ae-912e-45d6-7048135ada2e@rt-rk.com> <alpine.DEB.2.00.1710301253210.3886@tp.orcam.me.uk> <alpine.DEB.2.00.1711072118230.10088@tp.orcam.me.uk> <9461a925-363c-cc90-0a01-298da75ae00e@redhat.com>
On Wed, 8 Nov 2017, Pedro Alves wrote:
> > So I have looked into it now and tracked down `libthread_db' rather
> > than GDB to be the component requiring PID retrieval from a core file
> > for TLS access to work, and then only before glibc commit c579f48edba8
> > ("Remove cached PID/TID in clone"), which was first included in 2.25
> > glibc release.
> >
> > Given I have been using recent glibc checkouts for MIPS verification I
> > avoided the requirement, but I was indeed able to reproduce it natively
> > with x86-64 and the system-supplied `libthread_db', and then with my
> > MIPS environment as well, once I went with my glibc build back to commit
> > c579f48edba8^.
> >
> > I will be adding a reference to said glibc commit when pushing your 2/3
> > change.
>
> Interesting, hadn't realized libthread_db stopped requiring this.
> I wonder whether it'd be a good idea to mention it in the code itself
> too, say, in proc-service.:ps_getpid.
This might not be the best place. Calls to `ps_getpid' are still made
from places throughout `libthread_db', and it's only one from
`td_ta_thr_iter' (which matters here) whose result is discarded, by only
passing it down to `iterate_thread_list' to become its ignored
`match_pid' argument. This looks like an oversight of some kind to me,
which Adhemerval might be able to shed some light on.
Adhemerval, in your commit referred above, corresponding to the change
held at: <https://sourceware.org/ml/libc-alpha/2016-11/msg00282.html>,
you made the `match_pid' argument of `iterate_thread_list' unused. The
function is static, called from `td_ta_thr_iter' only (and I actually
wonder why the build does not trip on an unused argument here).
Is it OK then to remove the argument then along with the `ps_getpid'
call in `td_ta_thr_iter' used to set the corresponding parameter, or is
there something missing from there you intended to do and `match_pid'
was meant to remain used?
NB I would post a clean-up proposal, but regrettably my company FSF
copyright assignment status is in a limbo state right now, after the
transition from Imagination to the new MIPS company, and I'd rather not
block the cleanup by posting a patch that cannot move forward. Or would
it be small enough to qualify as not needing an assignment? Hmm...
As to choosing the right place to comment on this `libthread_db'
semantics change, I think either the call to `bfd_core_file_pid' made
from `add_to_thread_list' in corelow.c or the heading of the latter
function might be better, as this is where the consumer of BFD's core
file data PID is. Adding a comment like this might be small/trivial
enough for me to sneak in while the FSF paperwork is still pending.
Maciej