From: Simon Marchi <simon.marchi@polymtl.ca>
To: John Baldwin <jhb@freebsd.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 3/9] Handle TLS variable lookups when using separate debug object files.
Date: Sat, 02 Feb 2019 15:52:00 -0000 [thread overview]
Message-ID: <27bfe45d3ccba5f52d2e3632da417000@polymtl.ca> (raw)
In-Reply-To: <6f24b813adb0155b499d6e2265a6f15a2db4e6ca.1548180889.git.jhb@FreeBSD.org>
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?
Simon
next prev parent reply other threads:[~2019-02-02 15:52 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 7/9] Support TLS variables on FreeBSD/i386 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 9/9] Support TLS variables on FreeBSD/powerpc John Baldwin
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 [this message]
2019-02-04 20:02 ` John Baldwin
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 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 6/9] Support TLS variables on FreeBSD/amd64 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
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 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
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=27bfe45d3ccba5f52d2e3632da417000@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@sourceware.org \
--cc=jhb@freebsd.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