Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: John Baldwin <jhb@FreeBSD.org>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 3/9] Handle TLS variable lookups when using separate debug object files.
Date: Mon, 04 Feb 2019 20:02:00 -0000	[thread overview]
Message-ID: <ecba3439-8352-8e97-61ee-384c89bac2b3@FreeBSD.org> (raw)
In-Reply-To: <27bfe45d3ccba5f52d2e3632da417000@polymtl.ca>

On 2/2/19 7:52 AM, Simon Marchi wrote:
> On 2019-01-22 13:42, John Baldwin wrote:
>> The object files stored in the shared object list are the original
>> object files, not the separate debug object files.  However, when
>> resolving a TLS variable, the variable is resolved against a separate
>> debug object file if it exists.  In this case,
>> svr4_fetch_objfile_link_map was failing to find the link map entry
>> since the debug object file is not in its internal list, only the
>> original object file.
> 
> Does this solve an existing issue, or an issue that would come up with 
> the following patches?

I only noticed while working on these patches, but I believe it is a
generic issue.  I tried to reproduce on a Linux box by compiling a small
library with separate debug symbols and a program that linked against it
and running it under gdb, but TLS variables didn't work for me even without
separate debug symbols in my testing. :(

$ cat foo.c
#include "foo.h"

static __thread int foo_id;

void
set_foo_id(int id)
{
  foo_id = id;
}

int
get_foo_id(void)
{
  return foo_id;
}
$ cat foo.h
void set_foo_id(int id);
int get_foo_id(void);
$ cat main.c
#include <stdio.h>

#include "foo.h"

int
main(void)
{

  set_foo_id(47);
  printf("foo id = %d\n", get_foo_id());
  return (0);
}
$ cc -g -fPIC -shared foo.c -o libfoo.so.full
$ objcopy --only-keep-debug libfoo.so.full libfoo.so.debug
$ objcopy --strip-debug --add-gnu-debuglink=libfoo.so.debug libfoo.so.full libfoo.so
$ cc -g main.c -o foo -lfoo -L.
$ gdb foo
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
...
(gdb) start
Temporary breakpoint 1 at 0x7ae: file main.c, line 9.
Starting program: /home/john/tls_lib/foo 

Temporary breakpoint 1, main () at main.c:9
9         set_foo_id(47);
(gdb) p foo_id
Cannot find thread-local storage for process 3970, shared library libfoo.so:
Cannot find thread-local variables on this target

Then tried it without separate debug file, but that didn't work either:

$ cc -g -fPIC -shared foo.c -o libfoo.so
$ gdb foo
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
...
(gdb) start
Temporary breakpoint 1 at 0x7ae: file main.c, line 9.
Starting program: /home/john/tls_lib/foo 

Temporary breakpoint 1, main () at main.c:9
9         set_foo_id(47);
(gdb) p foo_id
Cannot find thread-local storage for process 3982, shared library libfoo.so:
Cannot find thread-local variables on this target
(gdb) n
10        printf("foo id = %d\n", get_foo_id());
(gdb) 
foo id = 47
11        return (0);
(gdb) p foo_id
Cannot find thread-local storage for process 3982, shared library libfoo.so:
Cannot find thread-local variables on this target

I would have expected the second case to work and the first to fail and for
the patch to fix the first case.

-- 
John Baldwin

                                                                            


  reply	other threads:[~2019-02-04 20:02 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 18:43 [PATCH 0/9] Support for thread-local variables on FreeBSD John Baldwin
2019-01-22 18:43 ` [PATCH 6/9] Support TLS variables on FreeBSD/amd64 John Baldwin
2019-01-22 18:43 ` [PATCH 2/9] Support fs_base and gs_base on FreeBSD/i386 John Baldwin
2019-02-02 15:26   ` Simon Marchi
2019-02-04 19:45     ` John Baldwin
2019-02-05 18:59       ` Simon Marchi
2019-01-22 18:43 ` [PATCH 9/9] Support TLS variables on FreeBSD/powerpc John Baldwin
2019-01-22 18:43 ` [PATCH 1/9] Support the fs_base and gs_base registers on i386 John Baldwin
2019-01-27  4:22   ` Simon Marchi
2019-01-28 17:54     ` John Baldwin
2019-02-02 15:11       ` Simon Marchi
2019-01-22 18:43 ` [PATCH 3/9] Handle TLS variable lookups when using separate debug object files John Baldwin
2019-02-02 15:52   ` Simon Marchi
2019-02-04 20:02     ` John Baldwin [this message]
2019-02-05 20:06       ` Simon Marchi
2019-02-05 22:21         ` John Baldwin
2019-02-05 22:33           ` John Baldwin
     [not found]             ` <67973931006085a171ad69952649de33@polymtl.ca>
2019-02-07  4:08               ` Simon Marchi
2019-01-22 18:43 ` [PATCH 7/9] Support TLS variables on FreeBSD/i386 John Baldwin
2019-01-22 18:52 ` [PATCH 5/9] Add a helper function to resolve TLS variable addresses for FreeBSD John Baldwin
2019-01-24 17:09   ` John Baldwin
2019-02-07  5:05     ` Simon Marchi
2019-02-07 17:02       ` John Baldwin
2019-02-09  0:34         ` John Baldwin
2019-01-22 18:52 ` [PATCH 4/9] Add a new gdbarch method to resolve the address of TLS variables John Baldwin
2019-01-22 18:52 ` [PATCH 8/9] Support TLS variables on FreeBSD/riscv John Baldwin
2019-01-27 23:35   ` Andrew Burgess

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=ecba3439-8352-8e97-61ee-384c89bac2b3@FreeBSD.org \
    --to=jhb@freebsd.org \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@polymtl.ca \
    /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