This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: Move cache line size to rtld_global_ro
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Tulio Magno Quites Machado Filho <tuliom at ascii dot art dot br>, law at redhat dot com, Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 9 Jan 2020 15:03:53 -0300
- Subject: Re: [PATCH] powerpc: Move cache line size to rtld_global_ro
- References: <mvmh82xeg6n.fsf@suse.de> <20191223184523.70113-1-tuliom@linux.ibm.com> <b719ad08-c818-7963-1b10-341f04af7c5e@linaro.org> <875zi16ai8.fsf@linux.ibm.com> <2fb22e3b-cc59-24e8-661b-6da39371bb84@linaro.org> <87zhew9b32.fsf@oldenburg2.str.redhat.com> <b8ad6fed0495158c4ea4e9ded99986cf688d9944.camel@redhat.com> <87pnfso8bi.fsf@linux.ibm.com>
On 09/01/2020 14:20, Tulio Magno Quites Machado Filho wrote:
> Jeff Law <law@redhat.com> writes:
>
>> On Thu, 2020-01-09 at 11:29 +0100, Florian Weimer wrote:
>>> What's the status here?
>>>
>>> I think it's desirable to fix this before the release.
>
> While working on the changes requested by Adhemerval, I hit 2 other bugs:
>
> 1. getauxval() does not work well from a DSO dlopen'ed by a statically linked
> executable.
This is BZ#20802 and I although we might fix it by adding the initialization
on dl-static.c, I think Florian suggestion [1] to proper initialize shared ld.so
variables is a better overall solution. However it is also a much more extensive
change and not feasible on current release phase.
> 2. errno from a DSO is lost in a statically linked executable (BZ #25335).
>
> I've fixed the first issue, but I'm stuck with the second one.
I don't see how easily we would fix it, it probability require to change
how errno is definde in static manner and most likely more hacks to use
the one from loaded libc.so. This would also require some discussion if it
is really an expected scenario we should support.
>
>> Presumably this fixes the problem with it being used as a common symbol
>> and thus not working with gcc-10 on ppc64? If so, yea, seems like it'd
>> be desirable before the release.
>
> The tests I implemented are failing because of these issues.
>
> Would it be fine if I disabled the failing tests while we do not have a fix
> for BZ #25335?
>
You can change the test to save/restore a passed errno in the wrapper
if it is required to check for errno value. I don't see provide a
fix for BZ#25535 as a blocker here.
[1] https://sourceware.org/ml/libc-alpha/2019-12/msg00483.html