Thursday, September 19, 2024
Richard Sandiford wrote:
> abs_hwi (const_offset) (since const_offset has HOST_WIDE_INT type).
abs_hwi has been applied.
> It might be easier to pass base and const_offset from the caller
> (aarch64_expand_mov_immediate). We are then guaranteed that the
> offset is
Friday, September 13, 2024
Martin Storsjö wrote:
>> When the offset is >= 1MB:
>>
>> adrp x0, symbol + offset % (1 << 20) // it prevents relocation overflow in
>> IMAGE_REL_ARM64_PAGEBASE_REL21
>> add x0, x0, (offset & ~0xf) >> 12, lsl #12 // a workaround to support
>> 4GB offset
>> add x0,
Richard Sandiford writes:
> Evgeny Karpov writes:
>> + {
>> + rtx const_int = imm;
>> + const_int = XEXP (const_int, 0);
>> + XEXP (const_int, 1) = GEN_INT(const_offset % (1 << 20));
>
> CONST_INTs are shared objects, so we can
Evgeny Karpov writes:
> The current binutils implementation does not support offset up to 4GB in
> IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
> This is related to differences in ELF and COFF relocation records.
> There are ways to fix this. This work on relocation change will
On Thu, 19 Sep 2024, Richard Sandiford wrote:
Martin Storsjö writes:
On Thu, 12 Sep 2024, Evgeny Karpov wrote:
The current binutils implementation does not support offset up to 4GB in
IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
This is related to differences in ELF and C
Martin Storsjö writes:
> On Thu, 12 Sep 2024, Evgeny Karpov wrote:
>
>> The current binutils implementation does not support offset up to 4GB in
>> IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
>> This is related to differences in ELF and COFF relocation records.
>
> Yes, I agre
On Thu, 12 Sep 2024, Evgeny Karpov wrote:
Thursday, September 12, 2024
Martin Storsjö wrote:
This looks very reasonable - I presume this will make sure that you only
use the other code form if the offset actually is larger than 1 MB.
For the case when the offset actually is larger than 1 MB,
Thursday, September 12, 2024
Martin Storsjö wrote:
> This looks very reasonable - I presume this will make sure that you only
> use the other code form if the offset actually is larger than 1 MB.
>
> For the case when the offset actually is larger than 1 MB, I guess this
> also ends up generating
On Thu, 12 Sep 2024, Evgeny Karpov wrote:
The current binutils implementation does not support offset up to 4GB in
IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
This is related to differences in ELF and COFF relocation records.
Yes, I agree.
But I would not consider this a
The current binutils implementation does not support offset up to 4GB in
IMAGE_REL_ARM64_PAGEBASE_REL21 relocation and is limited to 1MB.
This is related to differences in ELF and COFF relocation records.
There are ways to fix this. This work on relocation change will be extracted to
a separate bin
On Fri, 6 Sep 2024, Evgeny Karpov wrote:
Friday, September 6, 2024
Martin Storsjö wrote:
Sorry, but no.
You can't just redefine how relocations in your object file format works,
just because you feel like it.
This patch changes how symbol with offset will be emitted.
It will change:
adrp
Friday, September 6, 2024
Martin Storsjö wrote:
> Sorry, but no.
>
> You can't just redefine how relocations in your object file format works,
> just because you feel like it.
This patch changes how symbol with offset will be emitted.
It will change:
adrp x0, symbol + offset
to:
adrp x0, sym
On Fri, 6 Sep 2024, Evgeny Karpov wrote:
aarch64.cc has been updated to prevent emitting "symbol + offset"
for SYMBOL_SMALL_ABSOLUTE for the PECOFF target. "symbol + offset"
cannot be used in relocations for aarch64-w64-mingw32 due to
relocation requirements.
Instead, it will adjust the address
aarch64.cc has been updated to prevent emitting "symbol + offset"
for SYMBOL_SMALL_ABSOLUTE for the PECOFF target. "symbol + offset"
cannot be used in relocations for aarch64-w64-mingw32 due to
relocation requirements.
Instead, it will adjust the address by an offset with the
"add" instruction.
T
14 matches
Mail list logo
