Re: [RFC PATCH 0/3] Pretty-printing for errno

[Zack Weinberg <zackw@panix.com>]

On Wed, Sep 6, 2017 at 9:31 AM, Pedro Alves <palves@redhat.com> wrote:
> On 09/06/2017 02:05 PM, Zack Weinberg wrote:
>> I am not familiar with the glibc-side TLS implementation, nor with
>> libthread_db.so, nor the code in GDB that uses libthread_db.so.
>> However, reading the implementation of td_thr_tls_get_addr leads me to
>> believe that that function is *supposed* to work even if libpthread.so
>> has not been loaded into the 'inferior'.  If it doesn't, perhaps that
>> is a bug on our side.  Do you know if GDB even tries? It's not obvious
>> to me looking at linux-thread-db.c.
>
> GDB only tries to load libthread_db.so if it detects libpthread.so loaded
> in the inferior.  gdb/linux-thread-db.c:thread_db_new_objfile is called for
> every shared library found in the inferior.
>
> However, if we hack gdb like this to force it to always try to
> load libthread_db.so:
...

> That "td_ta_new failed: application not linked with libthread"
> error is output by thread_db_err_str in linux-thread-db.c.  It's
> just pretty-printing TD_NOLIBTHREAD.  I.e., opening a connection
> to libthread_db.so fails:
>
>   /* Now attempt to open a connection to the thread library.  */
>   err = info->td_ta_new_p (&info->proc_handle, &info->thread_agent);
>   if (err != TD_OK)
>     {
>
> Because lithread_db.so itself "rejects" the inferior.

So, changes to both gdb and libthread_db seem to be required here.  I
do think that _in principle_ it ought to be possible to use
libthread_db to retrieve the address of thread-local data even if the
inferior is not linked with libpthread; glibc has quite a few
thread-specific variables (errno most prominent, of course, but also
h_errno, _res, etc), and so might any library which can be used from
both single- and multithreaded programs.

This is really not code I feel comfortable hacking up, though, and
it's probably more of a project than I have time for, in any case.

...
>> called when the module is loaded; what would I need to add to that so
>> that the macro is defined (if it isn't already)?
>
> I'm hoping that other people more experienced with the gdb
> Python API can chime in.  My idea was just to call
>   gdb.execute ("macro define errno (*(int *) __errno_location ())")
> somewhere around your Python code.

I'll tinker with that.  Thanks.

zw