Re: RFC: Fix crash on i386 (%gs-)threaded programs using execve(2)

[Daniel Jacobowitz <drow@false.org>]

On Wed, Jun 14, 2006 at 12:55:10PM +0200, Jan Kratochvil wrote:
> It is only a heuristic as execve(2) destroys %gs and gdb(1) fails to find the
> no longer existing threads through TLS. Patch will warn and turn off the gdb(1)
> threads support if it finds out %gs==0.
> 
> On i386 with %gs based TLS NPTLS gdb calls glibc td_ta_map_lwp2thr() which
> calls ta_howto_reg_thread_area() (case ta_howto_reg_thread_area).
> After execve(2) it retrieves %gs as 0 and fails to ps_get_thread_area()
> as its idx must be 6 (glibc TLS descriptor) - value of the first/glibc Linux
> kernel GDT_ENTRY_TLS_MIN.
> It is now workarounded as to drop threading support if %gs==0.
> 
> Do you have an idea for a cleaner solution than this hack of waiting till the
> threads are no longer accessible?  Not aware of some indication which kernel
> syscall will replace the whole process memory space and the process registers.

Your problem combines two different issues:

- libthread_db doesn't do anything sensible at the beginning of
execution, before libpthread is initialized.  I filed a bug in the
glibc bugzilla about this with a possible patch.

- gdb thinks threading is still active after an exec.

We already have a way to detect exec events: PTRACE_EVENT_EXEC. 
Support for it is disabled, because it really doesn't work very well,
and no one has volunteered to fix it.  The way we handle it doesn't
make much sense; gdb silently switches the current executable file from
the old program to the new programl which messes up what happens when
the user says "run".

But if you wanted to support any kind of execve debugging, that would
be the way to do it.

Oh, and please don't add more tests to the testsuite which would spin
forever if detached from GDB; we've already got a few and I'm convinced
in hindsight that it was a mistake.  You only need it to exec once, so
you could make it quietly exit the second time.

-- 
Daniel Jacobowitz
CodeSourcery