search for: r_aarch64_prel32

Hi, On AArch64, I see a lot of warnings like: warning: failed to compute relocation: R_AARCH64_PREL32, Invalid data was encountered while parsing the file when opening object file with llvm-objdump. The llvm-objdump is from trunk at this moment. Is this easy to fix?

...(other cases) > > The address can be insignificant: ultimately the program will call the > function. There is no difference if the program calls the function > directly or calls through one PLT entry in any module (executable or a > shared object). > > R_386_PC32/R_X86_64_PC32/R_AARCH64_PREL32 Ignoring the ELF-specific bits, in essence, it's some dso-local function that's functionally equivalent to the actual resolved function at runtime. The address may or may not be equal to that of the resolved function. Maybe it would make sense to introduce a GlobalValue to represent this...

I do have concerns about the amount of object level modeling that we want to do in the IR though. While it isn't the highest level IR we've managed to mostly avoid these kinds of features/complications in the past. I'm definitely interested in hearing some alternate implementations here and there rather than a full set of constants for relocations. Keeping the IR abstract enough over

Hi all, We would like to propose a new Constant type in LLVM for representing entries in the Procedure Linkage Table (PLT). The PLT is a data structure used for dispatching position-independent function calls to appropriate functions where the address of the function is not known statically. Right now, if a call is made to a function, it may be lowered to a direct call to the function itself or