"addend too big for relocation" #52

ilg-ul · 2021-11-25T22:39:17Z

While compiling my packages on Apple Silicon, I occasionally encountered errors like this:

gcc-xbb -DHAVE_CONFIG_H -I. -I/Users/ilg/Work/qemu-arm-2.8.0-13/darwin-arm64/sources/pixman-0.40.0/test -I..  -I/Users/ilg/Work/qemu-arm-2.8.0-13/darwin-arm64/sources/pixman-0.40.0/pixman -I../pixman -I/Users/ilg/Work/qemu-arm-2.8.0-13/darwin-arm64/install/libs/include/libpng16 -I/Users/ilg/Work/qemu-arm-2.8.0-13/darwin-arm64/install/libs/include -I/Users/ilg/Work/qemu-arm-2.8.0-13/darwin-arm64/install/libs/include  -fopenmp  -ffunction-sections -fdata-sections -pipe -O2 -w -c -o affine-bench.o /Users/ilg/Work/qemu-arm-2.8.0-13/darwin-arm64/sources/pixman-0.40.0/test/affine-bench.c
<stdin>:593:2: error: addend too big for relocation
        adrp    x1, _clean_space.0@PAGE+8388608
        ^
<stdin>:595:2: error: addend too big for relocation
        add     x1, x1, _clean_space.0@PAGEOFF+8388608;momd
        ^
<stdin>:595:2: error: fixup value out of range
        add     x1, x1, _clean_space.0@PAGEOFF+8388608;momd
        ^
make[2]: *** [Makefile:1161: affine-bench.o] Error 1
make[2]: *** Waiting for unfinished jobs....

In some cases simply updating to the latest version of the package made the error go away, but in this case even with the latest release of pixman, and using the same configure flags as on HomeBrew, the issue persists.

The problem was also reported on stackoverflow, about some HomeBrew builds:

https://stackoverflow.com/questions/69696931/addend-too-big-for-relocation-error-reported-by-homebrew-g-installed-on-mac

Is this something related to GCC 11.1? If necessary, I can recreate my build environment with 11.2, if it is stable now.

The text was updated successfully, but these errors were encountered:

iains · 2021-11-25T23:17:40Z

While compiling my packages on Apple Silicon, I occasionally encountered errors like this:

https://stackoverflow.com/questions/69696931/addend-too-big-for-relocation-error-reported-by-homebrew-g-installed-on-mac

@fxcoudert
Why has this not been reported here?

I need a proper reproducer case to fix the bug complaining about bugs won't make them go away, they need fixing ..

Is this something related to GCC 11.1? If necessary, now I can recreate my build environment with 11.2, if it is stable now.

does your branch have this patch?:

2a516dc

(there is actually an assembler/link bug which is not representing negative values properly).

If the value is actually positive (which I can't tell without the reproducer) then that patch needs to be extended (I had a version that range-checked at one stage - but it never fired on any of the code in GCC).

ilg-ul · 2021-11-26T00:27:35Z

does your branch have this patch?:

If the question is for me, I don't know, I'm using the HomeBrew branch.

fxcoudert · 2021-11-26T07:21:25Z

Why has this not been reported here?

How should I know? I don't think it was reported to Homebrew either. I wasn't aware of it.

does your branch have this patch?: 2a516dc

Yes it does.

I need a proper reproducer case

I can reproduce with my patched 11.2:

meau /tmp $ cat a.cpp 
#include <bits/stdc++.h>
using namespace std;
vector<int> vec[1145140];
int main(){
    return 0;
}
meau /tmp $ g++-11 a.cpp 
/var/folders/h8/9hx_fyj91053ksgdzb2w03vw0000gp/T//ccJZqeGt.s:431:2: error: addend too big for relocation
        adrp    x0, _vec@PAGE+27483360
        ^
/var/folders/h8/9hx_fyj91053ksgdzb2w03vw0000gp/T//ccJZqeGt.s:432:2: error: addend too big for relocation
        add     x19, x0, _vec@PAGEOFF+27483360;momd
        ^
/var/folders/h8/9hx_fyj91053ksgdzb2w03vw0000gp/T//ccJZqeGt.s:432:2: error: fixup value out of range
        add     x19, x0, _vec@PAGEOFF+27483360;momd
        ^

The assembler produced can be found here: https://gist.github.com/fxcoudert/09f649d2613ae39a8c0f025d13f3a2df

iains · 2021-11-26T08:29:20Z

sigh, I've had a week of finding out that bugs have been reported everywhere but where I can see them ... sorry for being 'grumpy'. Let's take a look at that (it might be a code model problem too - given the array size).

fxcoudert · 2021-11-26T11:16:51Z

@iains I can feel your pain, I'm trying to help out users on Homebrew forums as well. We had a report of failure to allocate big chunks of static memory here Homebrew/discussions#2520 (reply in thread) but it seems to be a generic limitation, since I can reproduce that in C with clang.

iains · 2021-11-26T13:54:36Z

this bug is confirmed (issue 52), I have an idea how to fix it .. but not tried yet.

I suspect that discussions#2520 relates to code model - presumably since the static allocation is 2Gb that exceeds the addressability of small code model. IIRC x86_64 had this problem too (still does on GCC, but I think clang is fixed).

-- you might want to investigate if there's a large code model for aarch64-darwin (I did not implement one so far).

ilg-ul · 2021-11-26T14:24:47Z

I have an idea how to fix it .

Great!

In the mean time I also had an idea how to avoid the bug... I compiled pixman with Apple clang instead of GCC ;-)

This fixes issue #52. We need to constrain the offsets in the @PAGE/@PAGEOFFS relocations to fit in a 24bit field - +/- 8Mb. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ * config/aarch64/aarch64.c (aarch64_load_symref_appropriately): If the offset will not fit into the relocation, then rewrite it as an addition.

iains · 2021-11-26T19:36:52Z

fixed by 040bb28

This fixes issue #52. We need to constrain the offsets in the @PAGE/@PAGEOFFS relocations to fit in a 24bit field - +/- 8Mb. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ * config/aarch64/aarch64.c (aarch64_load_symref_appropriately): If the offset will not fit into the relocation, then rewrite it as an addition.

Base build changes to Darwin common code. It seems that the arm64 port will not make use of traditional mach-o pic but instead use a GOT - as such, the target-dependent parts of darwin.c are made NOP for this. We still expect to apply other Mach-O constraints. Most of the change is about the support for giving the user an error message when they try to invoke the compiler with multiple -arch flags. There is no provision in the initial port to handle the arm64_32 variant. This is (understood to be) only used in watchOS which we are not supporting initially. + No machopic indirections for Arm64 personality/LSDA entries. As for x86-64 (64bit code), the personality and LSDA .cfi_xxx entries do not require an indirection in the compiler code. + Accept arm64 in arch flags, for aarch64 compilers. We were checking for this and complaining if it was present for an X86 or PPC compiler, but we also need to accept (and ignore it) for an aarch64 / Arm64 compiler. This is enough to make a buildable cross-compiler on x86_64 Darwin and compile trivial codes. Although the link phase might not succeed - one can link objects manually and get an exe that works. There's an initial implementation of the rule changes for darwinpcs. There's an initial (pretty hacky) set of changes to deal with the post-fix assembly notation for Mach-O relocs. There are a few places where ELF was assumed, and we need to prevent incompatible output for Mach-O (probably there are other ways to do this). + Pick up atomic builtins from the libgcc.a CHECKME: should these be exported from the shared lib? (at present, that doesn't seem to be ideal). Look at what's done for the clang toolchain. + long double is DF not TF :( We will need to figure out what to do about supporting XXX*16 a some point. + Fix ptrdiff type. This was wrong (the size needs to track the 64-bitness and was failing to do so. + Add in driver sef-specs. Ensure that we issue the Darwin driver self specs and set the mabi and little-endian flags. clang accepts -mabi=darwinpcs so we allow that (but it means the same as lp64 at present since the target is determined at configuration time). + Fix an other build error for Darwin. Since we don't emit ELF function decorations this means that some of the variables are unused. + Initial implementation for EH without .cfi_xxxx While we can (most likely) make the .cfi_ codegen work, there are comments in the Ada code that suggest the capabilities of the unwinder are somewhat restricted. At least this option allows for the case of using libgcc_eh when an exe is self-contained. + Just whitespace fixes NFC. + We don't yet support TF, so reject 'q' suffix. The floating point literal suffix 'q' is specifically stated to be used for _float128, which we don't yet support. + Connect up the subtarget builtins i.e. __builtin_cfstring. The idea of OS-specific subtarget builtins doesn't fit too well with the general organisation of the aarch64 ones. What this does is to add it into the "GENERAL" class (but the darwin-specific code has no idea that the builtin code number has subfields). + Build fix for subtarget builtins. One either needs to define SUBTARGET_INIT_BUILTINS to empty or conditionalize its use + Connect up the sub-target attribute table. Darwin has some Mach-O / OS attributes, add these to the end of the aarch64 set.. + Connect up the pragma table. Darwin has some Mach-O / OS-specific pragmas, connected these to the end of the aarch64 table. gcc/ChangeLog: * config.gcc: Handle aarch64 and arm64 darwin. * config/aarch64/aarch64-protos.h (enum aarch64_symbol_type): Provide for symbol classifications for Mach-O. * config/aarch64/aarch64.c (aarch64_elf_asm_destructor): Don't define these for Mach-O (it's not ELF!). (handle_aarch64_vector_pcs_attribute): Handle darwinpcs. (aarch64_reg_save_mode): Likewise. (aarch64_load_symref_appropriately): Handle Mach-O. (aarch64_expand_mov_immediate): Likewise. (aarch64_layout_arg): Handle darwinpcs rules. (aarch64_function_arg): Likewise. (aarch64_init_cumulative_args): Likewise. (aarch64_function_arg_advance): Likewise. (aarch64_print_operand): Likewise (we can probably do better). (aarch64_print_address_internal): Likewise. (aarch64_asm_output_labelref): Likewise. (initialize_aarch64_code_model): Accept large PIC for Mach-O - of course, that doesn't mean it works. (aarch64_classify_symbol): Only emit ELF directives if they are available. (aarch64_declare_function_name): Likewise. (aarch64_asm_output_alias): Likewise. (aarch64_sls_emit_shared_blr_thunks): Likewise. (TARGET_ASM_UNALIGNED_HI_OP): New. (TARGET_ASM_UNALIGNED_SI_OP): New. (TARGET_ASM_UNALIGNED_DI_OP): New. * config/aarch64/aarch64.h (TARGET_MACHO): Declare as 0. (enum arm_pcs): Add darwinpcs. (SUBTARGET_EXTRA_SPECS): New. (EXTRA_SPECS): Allow for sub-target specs. * config/aarch64/aarch64.md (unspec enum): Add UNSPEC_MACHOPIC_OFFSET. (ldr_got_small_<mode>): Allow for postfix assembler syntax. (ldr_got_small_<mode>): Likewise. * config/aarch64/darwin.h: New file. * config/aarch64/t-aarch64-darwin: New file. Darwin, Arm64: Adjust NO_PIE spec for aarch64. Since aarch64 Darwin does not permit no-PIE, the linker warns that the option is ignored. Adjust the spec so that we do not send the option to the linker. gcc/ChangLog: * config/aarch64/darwin.h (DARWIN_NOPIE_SPEC): Revise for the aarch64 port. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> Darwin, Arm64 : Allow m64 on the command line. It seems that some people have makefiles etc. that put '-m64' for arm64 Darwin. This is allowed by clang. For the GCC version we make it an alias of -mabi=darwinpcs. aarch64, Darwin: Enable section anchors on -fsection-anchor. This is an experimental feature and might well require amendment to cater for constraints of the ld64 atom model. TODO: in supprot of that comment: 1. make the anchor base linker-visible 2. ensure that all offsets from that are local symbols. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ChangeLog: * config/aarch64/darwin.h (TARGET_ASM_OUTPUT_ANCHOR, TARGET_USE_ANCHORS_FOR_SYMBOL_P, DARWIN_SECTION_ANCHORS): New. * config/aarch64/aarch64.c (aarch64_darwin_use_anchor_for_sym_p): Delete. (TARGET_USE_ANCHORS_FOR_SYMBOL_P): Delete. aarch64, Darwin: Ignore mdynamic-no-pic. Match the behaviour of clang in ignoring the setting of mdynamic-no-pic either on the command line or as an option to cc1. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> Darwin, Arm64 : Assign a register for the static chain. At present, we do not have a workable solution for trampolines for the Darwin Arm64 port. Executable stack is not an option and the advice from Arm is not to use any lower address bits to signal that we have a descriptor. It is possible that we might be able to load some remappable object (e.g. a dylib) - but the details there still have to be resolved. In any case, we need a usable static chain - and the port has that assigned to R18 by default - which is the platform register in darwinpcs. It's uncertain whether R16/R17 are actually used in the darwinpcs in the role of support for branch islanding. The AAPCS64 use as IP0/1 is conditional on ELF relocations, so perhaps irrelevant to Darwin. Using R16 does not conflict with the existing (non-functional) trampoline code. lots of TODOs here. aarch64, Darwin: Use darwin_binds_local_p for the target. We dind locally for PIC code (the default) on Darwin so that the default implementations will not work as expected. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ChangeLog: * config/aarch64/darwin.h (TARGET_BINDS_LOCAL_P): New. Use darwin_bind_local_p() for this. aarhc64, Darwin: Do not give file-scope variables extra alignment. At lest, not until we determine the consequences of inter-operating with clang. Addresses Issue #68 Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ChangeLog: * config/aarch64/darwin.h (DATA_ALIGNMENT): Just use the alignment of the underlying object for now. aarch64 : Cast print value per format description. Fixes a build fail. Darwin, Arm64 : Truncate char immediates in vector initializers to mode size. Darwin has signed chars, so that 8b immediates > 127 appear to be negative which produce large positive (out of assembler range) values when inspected by UINTVAL (). This patch truncates the values to the bitrange of the mode of the input. Fixes github issue 15. Darwin, Arm64 : Implement darwinpcs mangling for va_list. The darwinpcs says this must be mangled as char * (Pc) and not presented in the std:: namespace. aarch64, Darwin: Implement darwinpcs D.2 This allows us to pass items smaller than 8 bytes with their natural alignment packed as appropriate into the stack. This means that multiple args can use one AAPCS64 stack slot. We continue to account the stack in terms of words, but for darwinpcs the last word in the cumulative arguments is filled incrementally. So the allocation will remain 8-byte-wise, but the filling can be 1-byte aligned. This also means that darwinpcs needs to override the standard hook for TARGET_FUNCTION_ARG_ROUND_BOUNDARY. It turns out that trying to implement the Darwin PCS as CC variation is a can of worms and, since the target is chosen at configure time, not actually doing anything useful. Fallout from this included clobbering of callee saved regs etc. So - for now at least - back out of this and use the AAPCS64 as the darwinpcs, with the TARGET_MACHO flag chosing the variant. It is likely that we need to separate things more, since we haven't fully dealt with the variadic functions issue properly. Darwin, Arm64 : Additional change for darwincpcs D.4. We are allowed to pass 16bytes in regs even if the starting reg is not even-numbered. aarch64, Darwin: Adapt shared blr thunks for Darwin ABI. For Darwin we just emit the thunks as wek defintions. TODO: really we should emit this stuff before debug. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ChangeLog: * config/aarch64/aarch64.c: Emit shared blr thunks as weak definitions. aarch64, Darwin: Initial support for relocations and asm syntax. At present, we are generating _foo+123@PAGE and we should have _foo@PAGE+123 etc. This can probably be fixed better with symbol flags and use of ASM_OUTPUT_SYMBOL_REF but that needs more work. Right now we're also stuck with GCC producing _foo@PAGE-1 as an example ... and the assmbler doesn't like it. Darwin, Arm64 : Make code label references use PAGE relocs We need to be able to refer to Lxxxx labels in libgnat. Darwin, Arm64 : Avoid negative offsets in PAGE relocs. It's not clear to me whether this is a mistake in the LLVM backend or a genuine restriction in the relocation (the wording of the addend reloc says neither 'signed' nor 'unsigned'. This works around this by making known negative offsets non-legitimate and composing the address by: ardp foo@PAGE add dest, temp, foo@PAGEOFF add dest, dest, neg_offset + We are now handling negative addends. Part of the code attempting to deal with the "PAGE-N" issue was to reject negative offsets in the legitimizers - actually, this wasn't effective anyway. We've now got code catching the cases and using a separate sum instruction, so delete these. aarch64, Darwin: Constrain page offset values to fit in the relocation. This fixes issue #52. We need to constrain the offsets in the @PAGE/@PAGEOFFS relocations to fit in a 24bit field - +/- 8Mb. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ * config/aarch64/aarch64.c (aarch64_load_symref_appropriately): If the offset will not fit into the relocation, then rewrite it as an addition. aarch64, Darwin: Account for UNSPEC_SALT_ADDR in symbol output. We were omitting the postfix relocation indicator because the code was falling back to the default output when a symbol was wrapped in an unspec SALT_ADDR. fixes issue #54. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> aarch64, Darwin: Allow for indexed address forms for PAGE+offset. We have been generating code like: adrp x0, sym@PAGE add x0, x0, sym@PAGEOFFS ld d0, [x0] now we generate: adrp x0, sym@PAGE ld d0 [x0, #sym@PAGEOFFS] and simmilarly for GOT accesses. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> gcc/ChangeLog: * config/aarch64/aarch64.c (aarch64_classify_address): Allow Mach-O PC relative accesses to constant pool and other defined objects. (aarch64_classify_symbol): Check for constant pool SYMREFs and only if it is not one check the Mach-O SYMBOL flags. aarch64, Darwin: Initial support for variadic function differences. These use the simpler char * version - but it remains to be seen if we need a non-standard rendition to cater for any amusing platform differences. Darwin, Arm64 : Adjust cases where stack spills pack differently. + Temporary handling for complex values. Complex values with a total size less than one stack slot might conceivably be packed in the same manner as other small values. However, this is not done - and we need to override the process for them. + Don't pack small structs either. Darwinpcs doesn't mention some things - and one is small structs. These are put into regs - but, when they spill to the stack, they don't pack in the manner of char, int et. al. + Handle HFA cases that have packed stack layout. bleah! (not sure this is complete). + Exclude unions from packing rule. + Hide an unused function. We are not using aarch64_vfp_is_call_candidate so wrap it in an #ifdef. + Fix a build error. Drop an unused var. Darwin, Arm64 : Account for stack addresses less aligned than DI. darwinpcs, packs some stack items, which means that one cannot guarantee that they are aligned to DI. Check for these cases and reject PRFM instructions then. Note, that this generally results in use of an extra temporary reg. clang uses 'PRFUM' instructions in those cases, so we have a missed optimisation opportunity (low priority). fixes issue #16. aarch64, Darwin: Handle prfm/prufm to support LLVM assemblers. 1. aarch64, Darwin : Restrict offsets for prfm. The current LLVM-based assemblers reject offsets that are not suitable for prfm as written in the local section. However, there is advice elsewhere that says that this category of instruction should attempt to use the 9bit unscaled version before falling back to the scaled one. In the short-term reject values that the assembler will not accept. This partially addresses Issue #43 gcc/ * config/aarch64/aarch64.c (aarch64_address_valid_for_prefetch_p): Reject values incompatible with pfrum and out of range for pfrm. For Mach-O, reject values that require prfum. 2. aarch64, Darwin : Match conditions for a PRFUM insn. This unpessimizes the prefetch cases for Darwin where the assembler is not able to substitute the prfum instructions automagically. This improves the fix for Issue #43. * config/aarch64/aarch64-protos.h * config/aarch64/aarch64.c * config/aarch64/aarch64.md * config/aarch64/constraints.md * config/aarch64/predicates.md Darwin, aarch64: Document the ABI (darwinpcs) and changes from that. Darwin,aarch64: Limit PAGE offsets to positive values for Darwin. Because of an assembler/linker bug, we cannot currently accept negative offset values for PAGEOFF relocations. While we were already catching this in expansion, there are cases where combine can produce values that need to be excluded. So reject symbol_refs with negative offsets.

iains closed this as completed Nov 26, 2021

ilg-ul mentioned this issue Nov 26, 2021

BOOT_LDFLAGS=-Wl,-headerpad_max_install_names ineffective #53

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

"addend too big for relocation" #52

"addend too big for relocation" #52

ilg-ul commented Nov 25, 2021 •

edited

Loading

iains commented Nov 25, 2021

ilg-ul commented Nov 26, 2021

fxcoudert commented Nov 26, 2021

iains commented Nov 26, 2021

fxcoudert commented Nov 26, 2021

iains commented Nov 26, 2021

ilg-ul commented Nov 26, 2021

iains commented Nov 26, 2021

"addend too big for relocation" #52

"addend too big for relocation" #52

Comments

ilg-ul commented Nov 25, 2021 • edited Loading

iains commented Nov 25, 2021

ilg-ul commented Nov 26, 2021

fxcoudert commented Nov 26, 2021

iains commented Nov 26, 2021

fxcoudert commented Nov 26, 2021

iains commented Nov 26, 2021

ilg-ul commented Nov 26, 2021

iains commented Nov 26, 2021

ilg-ul commented Nov 25, 2021 •

edited

Loading