[Bug 179072] _dl_debug_state() RT_CONSISTENT called too early

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=179072





--- Comment #12 from Jan Kratochvil <jan.kratochvil at redhat.com>  2008-11-12 17:38:41 EDT ---
Created an attachment (id=323394)
 --> (https://bugzilla.redhat.com/attachment.cgi?id=323394)
Minimized to only move _dl_debug_state() after relocations, for
glibc-2.8.90-16.

(In reply to comment #0)
> The time to call _dl_debug_state() is just before running the initializer
> functions of the newly-loaded objects.

_dl_debug_state() call be probably called at three places:
(A) r_map is already correct (guaranteed by RT_CONSISTENT); current version.
(B) Like (A) but also after the relocations are resolved.
(C) Like (B) but also after the initializers are executed.

I believe the call+RT_CONSISTENT was intended for (A) and neither (B) nor (C).
(C) is probably too late because we would not be able to debug initializers.
But still nobody guarantees we should stop at (B) instead of at current (A).

------------------------------------------------------------------------------

GDB currently assumes that at _dl_debug_state() time if the `nptl_version',
`_thread_db_*' and other symbols are present libthread_db can be used.

This is currently not true as it fails at least while reading libpthread
unrelocated symbol `stack_used':
glibc-20081031T2102/nptl/allocatestack.c:
static LIST_HEAD (stack_used);
File: /lib64/libpthread.so.0
Symbol table '.symtab' contains 907 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
    61: 0000000000217220    16 OBJECT  LOCAL  DEFAULT   28 stack_used
Relocation section '.rela.dyn' at offset 0x41a8 contains 68 entries:
  Offset          Info           Type           Sym. Value   Sym. Name + Addend
000000217220  000000000008 R_X86_64_RELATIVE                   0000000000217220

No other _dl_debug_state() call is done at a later time so the debugger cannot
start tracking the threads.

The only possibility is to delay libthread_db initialization by placing
a breakpoint at the _dl_debug_state() notification time to the function found
for DT_INIT.  While I implemented the attached GDB patch and so I do not try to
avoid this place for the fix I do not find it as the right solution.

------------------------------------------------------------------------------

Another possibility is to fix libpthread data structures to be fully PIC and so
understandable by libthread_db at the current _dl_debug_state() point (A).
It seems libthread_db can already parse libpthread at (B) time still before its
__pthread_initialize_minimal() is called from DT_INIT.
I find it also as a real possibility how to fix glibc libthread_db.

Still I do not see there a regression risk to delay _dl_debug_state() after
relocations resolving; there is nothing more useful on an unrelocated library.
(STT_IFUNC code - called code returning a value for relocations - would be
a bit harder to debug but only for resolving with RTLD_NOW - not a problem.)

Adjusted the patch for glibc-2.8.90-16 making it a minimal working change.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.