> De : Joerg Sonnenberger [mailto:joerg at britannica.bec.de] > > Well, MCFixup is what a relocation is represented as internally. They get > resolved to a fixed value and replaced, if evaluateAsAbsolute is true. >Hi Joerg, Actually it fails to get resolved to a fixed value. When I compile to .o then objdump it I can see that a symbol holding the constant value was created in .rodata.cst4 section. Since it is not in .text section, it sound logical that llvm cannot resolved it at assemble time. Is there a way to tell llvm to put the constant in .text section ? $ cat imm.c int imm32(){ return 0x04050607; } $ llvm-objdump -disassemble -s imm.o [...] Contents of section .rodata.cst4: 0000 07060504 [...]
On 30 June 2015 at 06:23, HEITZMANN Frédéric 218168 <frederic.heitzmann at cea.fr> wrote:> Is there a way to tell llvm to put the constant in .text section ?You'd need some kind of stubbed version of ConstantIslands that just put the islands at the beginning or end of a function. It would be much simpler than the ARM version though (at least initially), most of the complexity comes from finite reachability. But there's a lot to be said for just letting it stay in .rodata. The linker's going to be doing that kind of job anyway, so just let it get on with resolving offsets. Both x86 and AArch64 take this approach (in AArch64's case despite there being explicit instructions in the architecture designed to handle inline constants -- we just decided it wasn't worth the aggro of duplicating ARM's ConstantIsland mess so they're unused in LLVM). Cheers. Tim.
On Tue, Jun 30, 2015 at 08:02:21AM -0700, Tim Northover wrote:> > But there's a lot to be said for just letting it stay in .rodata. The > linker's going to be doing that kind of job anyway, so just let it get > on with resolving offsets. Both x86 and AArch64 take this approach.X86 is a bad example, because the normal code models allow addressing anything in the same object, pretty much independent of size constraints and section order. Joerg