On 12 February 2014 02:29, Kugan <kugan.vivekanandara...@linaro.org> wrote: > Hi, > > I finally got around to checking the attached patch for the > https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1270789 > > I noticed attached patch causes regression for pr38151.c in gcc test-suite. > > A reduced test-case that triggers this is: > static unsigned long global_max_fast; > int __libc_mallopt (int param_number, int value) > { > __asm__ __volatile__ ("# %[_SDT_A2]" :: [_SDT_A2] "nor" > ((global_max_fast))); > global_max_fast = 1; > } > > In this regard I have couple of questions: > > 1. Is the in-line asm valid? Look ok to me. > 2. For the pr38151.c regression, asm diff is as shown below. > > < add x0, x0, :lo12:.LANCHOR0 > < ldr x0, [x0] > --- >> ldr x0, [x0,#:lo12:.LANCHOR0] > > This causes: > pr38151.c:(.text+0x10c): relocation truncated to fit: > R_AARCH64_LDST64_ABS_LO12_NC against `.rodata' > collect2: error: ld returned 1 exit status. > > If I however increase the alignment of .rodata where .LANCHOR0 is > defined, this passes. Is alignment of BITS_PER_UNIT valid for > SYMBOL_REF? If I change it as I am doing this attached patch, is there > anything else I need to do.
>From the ARMARM: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0487a.b/index.html The range on an LDR is: <simm> Is the signed immediate byte offset, in the range -256 to 255, encoded in the "imm9" field. <pimm> For the 32-bit variant: is the optional positive immediate byte offset, a multiple of 4 in the range 0 to 16380, defaulting to 0 and encoded in the "imm12" field as <pimm>/4. <pimm> For the 64-bit variant: is the optional positive immediate byte offset, a multiple of 8 in the range 0 to 32760, defaulting to 0 and encoded in the "imm12" field as <pimm>/8. So in this case where we're taking the low 12-bits of ANCHOR0 we should be ensuring it is aligned to 8-bytes (or less than 256 - but we can't necessarily tell that at compile time). So I think your patch is correct - the symbol needs to be aligned to the size of the thing the symbol points to. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
