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
                                                                           Â
next prev parent 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