From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34015 invoked by alias); 4 Feb 2019 20:02:42 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 34005 invoked by uid 89); 4 Feb 2019 20:02:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx2.freebsd.org Received: from mx2.freebsd.org (HELO mx2.freebsd.org) (8.8.178.116) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Feb 2019 20:02:40 +0000 Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 3C3818BAD9; Mon, 4 Feb 2019 20:02:39 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 805756FA85; Mon, 4 Feb 2019 20:02:38 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id E822A549A; Mon, 4 Feb 2019 20:02:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [PATCH 3/9] Handle TLS variable lookups when using separate debug object files. To: Simon Marchi Cc: gdb-patches@sourceware.org References: <6f24b813adb0155b499d6e2265a6f15a2db4e6ca.1548180889.git.jhb@FreeBSD.org> <27bfe45d3ccba5f52d2e3632da417000@polymtl.ca> From: John Baldwin Openpgp: preference=signencrypt Message-ID: Date: Mon, 04 Feb 2019 20:02:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <27bfe45d3ccba5f52d2e3632da417000@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 805756FA85 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US] X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00018.txt.bz2 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 #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                                                                            Â