Wilco Dijkstra via Gcc-patches writes:
> Hi Richard,
>> Hmm, OK. I guess it makes things more consistent in that sense
>> (PIC vs. non-PIC). But on the other side it's making things less
>> internally consistent for non-PIC, since we don't use the GOT for
>> anything else there. I guess in prin
Hi Richard,
> Hmm, OK. I guess it makes things more consistent in that sense
> (PIC vs. non-PIC). But on the other side it's making things less
> internally consistent for non-PIC, since we don't use the GOT for
> anything else there. I guess in principle there's a danger that a
> custom *-elf
Wilco Dijkstra via Gcc-patches writes:
> Hi Richard,
>
>> Just to check: I guess this part is an optimisation, because it
>> means that we can share the GOT entry with other TUs. Is that right?
>> I think it would be worth having a comment either way, whatever the
>> rationale. A couple of other
Hi Andrew,
> I thought that was changed not to use the GOT on purpose.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63874
>
> That is if the symbol is not declared in the TU, then using the GOT is
> correct thing to do.
> Is the testcase gcc.target/aarch64/pr63874.c still working or is not
> tes
On Wed, Apr 28, 2021 at 9:50 AM Wilco Dijkstra via Gcc-patches
wrote:
>
>
> Use a GOT indirection for extern weak symbols instead of a literal - this is
> the same as
> PIC/PIE and mirrors LLVM behaviour. Ensure PIC/PIE use the same offset
> limits for symbols
> that don't use the GOT.
I thoug
Hi Richard,
> Just to check: I guess this part is an optimisation, because it
> means that we can share the GOT entry with other TUs. Is that right?
> I think it would be worth having a comment either way, whatever the
> rationale. A couple of other very minor things:
It's just to make the code
Wilco Dijkstra via Gcc-patches writes:
> Use a GOT indirection for extern weak symbols instead of a literal - this is
> the same as
> PIC/PIE and mirrors LLVM behaviour.
Just to check: I guess this part is an optimisation, because it
means that we can share the GOT entry with other TUs. Is that
