This is the mail archive of the
mailing list for the glibc project.
Re: sysdeps/mach/hurd/profil.c (was: [PATCH] hurd: align -p and -pg behavior on Linux)
- From: Samuel Thibault <samuel dot thibault at gnu dot org>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, bug-hurd at gnu dot org, libc-alpha at sourceware dot org
- Date: Thu, 25 Feb 2016 15:23:13 +0100
- Subject: Re: sysdeps/mach/hurd/profil.c (was: [PATCH] hurd: align -p and -pg behavior on Linux)
- Authentication-results: sourceware.org; auth=none
- References: <20150919120023 dot GA12911 at var dot home> <87bn75ybeb dot fsf at kepler dot schwinge dot homeip dot net> <8760xcyjfi dot fsf at kepler dot schwinge dot homeip dot net>
Thomas Schwinge, on Thu 25 Feb 2016 15:05:21 +0100, wrote:
> Should we move the initialization of profil_reply_port elsewhere, or be
> prepared for profil_reply_port to be MACH_PORT_NULL in
> sysdeps/mach/hurd/profil.c:fetch_samples (by returning early?), or not
> call fetch_samples from sysdeps/mach/hurd/profil.c:__profil if
> profil_reply_port is MACH_PORT_NULL, or make sure that we're always
> properly initialized by making sure that the profile thread is always
> scheduled to execute right after it's been created?
__profil calls __thread_suspend (profile_thread); then uses
fetch_samples. It seems unsafe to me to be using the profile thread's
reply port for the last profil_task_get_sampled_pcs call: who knows
where the thread got suspended?
> These days, do we still need the threadvar-avoidance magic, the "special
> RPC stubs", and the "special_profil_failure"?
With TLS support, I'd say we don't, which gets the profil_reply_port
> As there are accesses to variables shared between different threads,
> should these be re-written to use GCC's atomic/sync load/store builtins
> with appropriate semantics?
The current way seems unsafe at least between update_waiter and
fetch_samples, indeed. I'd say just go with a libc_lock.