From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Florian Weimer <fweimer@redhat.com>,
Thomas Fitzsimmons <fitzsim@fitzsim.org>
Cc: Mark Wielaard <mark@klomp.org>,
'GNU C Library' <libc-alpha@sourceware.org>
Subject: Re: [PATCH] Improve performance of IO locks
Date: Tue, 16 Aug 2022 10:24:57 +0000 [thread overview]
Message-ID: <AM5PR0801MB16684E546674DEAA3041BCFE836B9@AM5PR0801MB1668.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <878rnoeja2.fsf@oldenburg.str.redhat.com>
Hi,
>> I looked at elf/unload as an example; it's segfaulting in
>> _dl_relocate_object, backtrace attached; not sure what else to check.
>
> I don't see this on powerpc64, with a toolchain based on GCC 8.2 and
> binutils 2.30. I'm at a loss how these things could be related.
I would not expect the dynamic linker to have changed at all, so one option is
to check the binary is identical before/after my commit. If the dynamic linker
somehow got some uses of SINGLE_THREAD_P then that might access TLS
before it is setup.
The other possibility is that the binary it is trying to link has corrupted relocations.
It's hard to imagine how that could happen unless you use the new GLIBC to link
an application and fileio fails to write out the data for the relocations.
Cheers,
Wilco
next prev parent reply other threads:[~2022-08-16 10:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-08 16:32 Wilco Dijkstra
2022-08-01 11:06 ` Wilco Dijkstra
2022-08-07 12:51 ` Cristian Rodríguez
2022-08-15 22:27 ` Mark Wielaard
2022-08-16 3:07 ` Thomas Fitzsimmons
2022-08-16 7:31 ` Florian Weimer
2022-08-16 10:00 ` Mark Wielaard
2022-08-16 10:08 ` Florian Weimer
2022-08-17 13:45 ` Mark Wielaard
2022-08-22 10:25 ` Florian Weimer
2022-08-22 14:58 ` Frank Ch. Eigler
2022-08-16 11:19 ` Andreas Schwab
2022-08-16 10:24 ` Wilco Dijkstra [this message]
2022-08-16 13:18 ` Thomas Fitzsimmons
2022-08-16 14:31 ` Thomas Fitzsimmons
2022-08-17 11:53 ` Mark Wielaard
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=AM5PR0801MB16684E546674DEAA3041BCFE836B9@AM5PR0801MB1668.eurprd08.prod.outlook.com \
--to=wilco.dijkstra@arm.com \
--cc=fitzsim@fitzsim.org \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=mark@klomp.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).