search for: unrelocated

Hi llvm-community, I use llc (3.4-final) to generate object file: *llc code.bc -mtriple=x86_64-pc-win32-elf -mcpu=x86-64 -filetype=obj -code-model=large -o=code.o* then I load it with *RuntimeDyld + SectionMemoryManager* in my app. I faced the problem described in 15356 <http://llvm.org/bugs/show_bug.cgi?id=15356>bug. Debug assertion fails at

...LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Assertion fails resolving R_X86_64_PC32 relocation I ran into a similar error a while back and it turned out to be user error on my part. I had relocated some of the sections in the object file, but not others. As a result, I'd ended up with one (unrelocated) section with a reference to another (relocated) section which was more than 32 bits away. You may want to double check your memory layout. What caught my eye about your question was that ".eh_frame" was one of the sections in question for me too. Philip On 05/26/2014 08:51 AM, Aliaks...

...le.com> wrote: > For branch targets my preference is to print the target’s address (not the displacement of the branch), and preferably in hex. I like this too. > I don’t think having multiple addresses for a target is a real problem with the exception of the address 0 (which is often an unrelocated no addend value). So the trick is to not print the symbol name in the object with the address of zero in those cases Right, relocations are a special case.

I would like to improve llvm-objdump. However, many unit tests depend precisely on the current output, making the picture a little tricky. My experience is limited to ELF format objects, so experts in other formats please sanity check. Suggested changes: 1) Symbolize conditional branch targets. Currently, llvm-objdump prints branch targets numerically regardless of -symbolize. 2) Make

...s (via. `irg -> stg`) to each STO_TAGGED carrying global. b) Hidden Symbols (static int g; or -fvisibility=hidden) 1. Have the compiler mark hidden tagged globals in the symbol table as st_other.STO_TAGGED. 2. Have the linker read the symbol table and create a table of { unrelocated virtual address, size } pairs for each STO_TAGGED carrying hidden global, storing this in a new section (.mteglobtab). 3. Create a new dynamic entry "DT_MTEGLOBTAB" that points to this segment, along with "DT_MTEGLOBENT" for the size of each entry and "DT_MTEGL...

...GGED carrying global. > > > > b) Hidden Symbols (static int g; or -fvisibility=hidden) > > > > Have the compiler mark hidden tagged globals in the symbol table as > st_other.STO_TAGGED. > > > > Have the linker read the symbol table and create a table of { > unrelocated virtual address, size } pairs for each STO_TAGGED carrying > hidden global, storing this in a new section (.mteglobtab). > > > > Create a new dynamic entry "DT_MTEGLOBTAB" that points to this segment, > along with "DT_MTEGLOBENT" for the size of each entry and...

...; >>> > b) Hidden Symbols (static int g; or -fvisibility=hidden) >>> > >>> > Have the compiler mark hidden tagged globals in the symbol table as st_other.STO_TAGGED. >>> > >>> > Have the linker read the symbol table and create a table of { unrelocated virtual address, size } pairs for each STO_TAGGED carrying hidden global, storing this in a new section (.mteglobtab). >>> > >>> > Create a new dynamic entry "DT_MTEGLOBTAB" that points to this segment, along with "DT_MTEGLOBENT" for the size of each entr...

...0} << points to the same address as set by base address selection entry and has zero size. > >That's a bug in the producer (though a good point - I've probably made >that bug in LLVM) - the linker can't solve that problem, since the >linker can't touch the literal unrelocated 0, 0. > >> after linker resolved relocations it would look like this, for bfd case: >> >> base address selection entry: {-1, 1} >> following range list entry: {0, 0} <<<<<<<<<<< >> >> So there still exists {0,0} entry which cou...

...tic int g; or -fvisibility=hidden) > > > > 1. > > > > Have the compiler mark hidden tagged globals in the symbol table as > > st_other.STO_TAGGED. > > 2. > > > > Have the linker read the symbol table and create a table of { > > unrelocated virtual address, size } pairs for each STO_TAGGED carrying > > hidden global, storing this in a new section (.mteglobtab). > > 3. > > > > Create a new dynamic entry "DT_MTEGLOBTAB" that points to this > segment, > > along with "DT_MTEGLOBE...

...t; set by base address selection entry and has zero size. > > > > > >That's a bug in the producer (though a good point - I've probably made > > >that bug in LLVM) - the linker can't solve that problem, since the > > >linker can't touch the literal unrelocated 0, 0. > > > > > >> after linker resolved relocations it would look like this, for bfd > case: > > >> > > >> base address selection entry: {-1, 1} > > >> following range list entry: {0, 0} <<<<<<<<<<< > &...

...entry and has zero size. >>> > > >>> > >That's a bug in the producer (though a good point - I've probably made >>> > >that bug in LLVM) - the linker can't solve that problem, since the >>> > >linker can't touch the literal unrelocated 0, 0. >>> > > >>> > >> after linker resolved relocations it would look like this, for bfd case: >>> > >> >>> > >> base address selection entry: {-1, 1} >>> > >> following range list entry: {0, 0} <<<<...

...gt; > > > > >>> > >That's a bug in the producer (though a good point - I've probably > made > > >>> > >that bug in LLVM) - the linker can't solve that problem, since the > > >>> > >linker can't touch the literal unrelocated 0, 0. > > >>> > > > > >>> > >> after linker resolved relocations it would look like this, for > bfd case: > > >>> > >> > > >>> > >> base address selection entry: {-1, 1} > > >>> > >&...

...size. > >>> > > > >>> > >That's a bug in the producer (though a good point - I've probably made > >>> > >that bug in LLVM) - the linker can't solve that problem, since the > >>> > >linker can't touch the literal unrelocated 0, 0. > >>> > > > >>> > >> after linker resolved relocations it would look like this, for bfd case: > >>> > >> > >>> > >> base address selection entry: {-1, 1} > >>> > >> following range list entry...

>On Fri, Jul 17, 2020 at 1:55 PM Alexey Lapshin <a.v.lapshin at mail.ru> wrote: >> >> >Пятница, 17 июля 2020, 19:42 +03:00 от David Blaikie <dblaikie at gmail.com>: >> > >> >On Fri, Jul 17, 2020 at 12:03 AM Fangrui Song <maskray at google.com> wrote: >> >> >> >> Thanks for the write-up! >> >> >>

...; > >> > >>> > >That's a bug in the producer (though a good point - I've probably made >> > >>> > >that bug in LLVM) - the linker can't solve that problem, since the >> > >>> > >linker can't touch the literal unrelocated 0, 0. >> > >>> > > >> > >>> > >> after linker resolved relocations it would look like this, for bfd case: >> > >>> > >> >> > >>> > >> base address selection entry: {-1, 1} >> > >>...

...t; >That's a bug in the producer (though a good point - I've >> probably made >> >> > >>> > >that bug in LLVM) - the linker can't solve that problem, since >> the >> >> > >>> > >linker can't touch the literal unrelocated 0, 0. >> >> > >>> > > >> >> > >>> > >> after linker resolved relocations it would look like this, >> for bfd case: >> >> > >>> > >> >> >> > >>> > >> base address se...

...cer (though a good point - I've >> >> probably made >> >> >> > >>> > >that bug in LLVM) - the linker can't solve that problem, since >> >> the >> >> >> > >>> > >linker can't touch the literal unrelocated 0, 0. >> >> >> > >>> > > >> >> >> > >>> > >> after linker resolved relocations it would look like this, >> >> for bfd case: >> >> >> > >>> > >> >> >> >> &g...

...> >> >> probably made > > >> >> >> > >>> > >that bug in LLVM) - the linker can't solve that problem, since > > >> >> the > > >> >> >> > >>> > >linker can't touch the literal unrelocated 0, 0. > > >> >> >> > >>> > > > > >> >> >> > >>> > >> after linker resolved relocations it would look like this, > > >> >> for bfd case: > > >> >> >> > >>> &gt...

...de > > > > >> >> >> > >>> > >that bug in LLVM) - the linker can't solve that > problem, since > > > > >> >> the > > > > >> >> >> > >>> > >linker can't touch the literal unrelocated 0, 0. > > > > >> >> >> > >>> > > > > > > >> >> >> > >>> > >> after linker resolved relocations it would look > like this, > > > > >> >> for bfd case: > > > > &gt...

...> >> >> >> > >>> > >that bug in LLVM) - the linker can't solve that > problem, since > >> > > > >> >> the > >> > > > >> >> >> > >>> > >linker can't touch the literal unrelocated 0, 0. > >> > > > >> >> >> > >>> > > > >> > > > >> >> >> > >>> > >> after linker resolved relocations it would > look like this, > >> > > > >> >> for bfd ca...