Re: sysdeps/mach/hurd/profil.c (was: [PATCH] hurd: align -p and -pg behavior on Linux)

[Samuel Thibault]

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
issue away.

> 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.

Samuel