From: Ridley Combs <rcombs@rcombs.me>
To: musl@lists.openwall.com
Subject: Re: [musl] [PATCH] ldso: notify the debugger when we're doing a dlopen
Date: Sat, 24 Oct 2020 14:28:59 -0500 [thread overview]
Message-ID: <A91D03DF-4870-43BE-9EEC-8F6F7E27EBE2@rcombs.me> (raw)
In-Reply-To: <20201024154128.GE534@brightrain.aerifal.cx>
> On Oct 24, 2020, at 10:41, Rich Felker <dalias@libc.org> wrote:
>
> On Sat, Oct 24, 2020 at 12:31:56AM -0500, rcombs wrote:
>> Otherwise lldb doesn't notice the new library and stack traces containing it
>> get cut off unhelpfully.
>> ---
>> ldso/dynlink.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/ldso/dynlink.c b/ldso/dynlink.c
>> index fcc8f6a6..1ab9bf5b 100644
>> --- a/ldso/dynlink.c
>> +++ b/ldso/dynlink.c
>> @@ -1963,7 +1963,7 @@ void __dls3(size_t *sp, size_t *auxv)
>> debug.bp = dl_debug_state;
>> debug.head = head;
>> debug.base = ldso.base;
>> - debug.state = 0;
>> + debug.state = RT_CONSISTENT;
>> _dl_debug_state();
>>
>> if (replace_argv0) argv[0] = replace_argv0;
>> @@ -2012,6 +2012,10 @@ void *dlopen(const char *file, int mode)
>> pthread_rwlock_wrlock(&lock);
>> __inhibit_ptc();
>>
>> + int oldstate = debug.state;
>> + debug.state = RT_ADD;
>> + _dl_debug_state();
>> +
>> p = 0;
>> if (shutting_down) {
>> error("Cannot dlopen while program is exiting.");
>> @@ -2104,9 +2108,10 @@ void *dlopen(const char *file, int mode)
>> update_tls_size();
>> if (tls_cnt != orig_tls_cnt)
>> install_new_tls();
>> - _dl_debug_state();
>> orig_tail = tail;
>> end:
>> + debug.state = oldstate;
>> + _dl_debug_state();
>> __release_ptc();
>> if (p) gencnt++;
>> pthread_rwlock_unlock(&lock);
>> --
>> 2.17.1
>
> This looks good, but saving/restoring oldstate isn't necessary and
> doesn't make sense logically. The code here is taking place under an
> exclusive lock on the state. The initial state being consistent is a
> logical precondition to it, and a requirement for releasing the lock
> again when finished.
>
> Rich
Ah, I'd been thinking that dlopen might get called from within a ctor, but now that I look closer I see those are run after we set the state back anyway, so yeah this isn't needed.
next prev parent reply other threads:[~2020-10-24 19:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-24 5:31 rcombs
2020-10-24 15:41 ` Rich Felker
2020-10-24 19:28 ` Ridley Combs [this message]
2020-10-24 19:39 ` Rich Felker
2020-10-24 19:31 rcombs
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=A91D03DF-4870-43BE-9EEC-8F6F7E27EBE2@rcombs.me \
--to=rcombs@rcombs.me \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).