Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: gdb@sourceware.org
Subject: tcbhead_t gdb access for nonthreaded, gdb for longjmp()
Date: Fri, 08 Sep 2006 10:29:00 -0000	[thread overview]
Message-ID: <20060908102235.GA31335@host0.dyn.jankratochvil.net> (raw)

Hi,

crossposted to gdb+glibc as the patches closely correlate:

currently gdb/glibc cannot access TLS of debugged processes if compiled without
libpthread (nonthreaded).  Command line `print errno' produces one of:
	Cannot find thread-local variables on this target
	Cannot access memory at address 0x8
	[ gdb-20060908-tls-0.patch: gdb.threads/tls-print.exp ]

It also affects stepping over longjmp() as gdb calculates target address which
is PTR_MANGLE()d through TLS-based `pointer_guard' magic, as `next' will now:
	Cannot insert breakpoint -12.
	Error accessing memory address 0xb9227d3b: Input/output error.
	[ gdb-20060908-tls-0.patch: gdb.threads/tls-longjmp.exp ]

I would like to get approval of this design acceptance to finish the details.

glibc part:

 * Provide some access to the `tcbhead_t.pointer_guard' field for gdb.
   Currently implemented by `td_thr_getxregs' providing only `pointer_guard'.
   New non-Solaris `td_thr_*' function could be provided instead.

 * All the `libthread_db' functions accessing inferior's `_thread_db*' symbols
   of `libpthread' fallback to the new `_local_db*' symbols in `libthread_db'
   itself. `libthread_db'<=>`libpthread' versions must match anyway.
   I admit I do not know how may `libthread_db' and `libpthread' as there is
   already required in `td_ta_new' their versions match.  Anyway it should be
   enough for 99% of cases - as the fallback option.

gdb part:

 * `longjmp' decoder attempts to use `td_thr_getxregs', otherwise fallbacks
   to get the TLS base by `ps_get_thread_area' and the offset value
   `offsetof (tcbhead_t, pointer_guard)' from debuginfo, otherwise fallbacks
   to internal constant offset.

 * `SEC_THREAD_LOCAL' symbols are processed as a new expression data type.

 * TLS variables access uses legacy `thread_db_get_thread_local_address'
   as it depends on the `_local_db*' fallback implementation for nonthreaded
   processes missing `libthread_db' with the legacy `_thread_db*' symbols.


`longjmp' decoder can cope without glibc support by using debuginfo instead.
I would rather like to drop this workaround and rely on the glibc support.

TLS access needs the attached glibc patch for the nonthreaded processes.
I could provide gdb decoding without glibc support but I do not like it.

It works now only on i386, x86_64 to be debugged if it is accepted this way.
Patches still contain several FIXMEs; their fixes should not change the design.
glibc part should be arch-dependent, it will now fail to compile on arches
without existing `pointer_guard'.

Behavior changes depending on:
 * Application linked with libpthread or without libpthread.
 * glibc original/patched by this TLS extension.
 * -ggdb3 (overriding the TLS `errno' resolving just by the macro text).
 * Debuginfo availability for libpthread (for `longjmp').
Unfortunately the system changes cannot be tested just by the gdb testsuite.


Thanks,
Jan

Patches at: http://www.jankratochvil.net/priv/tls/


             reply	other threads:[~2006-09-08 10:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-08 10:29 Jan Kratochvil [this message]
2006-09-10 14:27 ` Daniel Jacobowitz
2006-09-13 13:05   ` Jan Kratochvil
2006-09-13 13:20     ` Daniel Jacobowitz
2006-09-13 18:37       ` Jan Kratochvil
2006-09-13 18:49         ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060908102235.GA31335@host0.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox