similar to: BLX relocation regression on Thumb2 bot

On 18 May 2016 at 15:12, Tim Northover <t.p.northover at gmail.com> wrote: > I don't suppose you could grab a -save-temps output for MallocChecker.cpp? Not from the bot any more. I didn't expect this to be a heisenbug. And I'm having trouble replicating it on my other machine. > I think we only produce R_ARM_THM_JUMP24 for tail calls. The veneer is > then needed if a

On 18 May 2016 at 17:32, Tim Northover <t.p.northover at gmail.com> wrote: > That's the thing: this shouldn't have changed at all recently. We emit > "b.w dest" with an R_ARM_THM_JUMP24 reloc. The linker then needs a > veneer if dest is out of range or an ARM function. Peter has just reminded me the fact that the relocation itself is in libstdc++, not on the

Hi all, I'm trying to figure out a problem with relocation types 1 and 8 (as observed using otool -r on ARM/Thumb object files). Earlier, when I used LLVM 2.8 with llc to generate thumb (-march=thumb -mattr=+thumb2) assembly listings, then assemble those using the gcc of iPhone 4.2 SDK, there wasn't any problem. However starting with LLVM 2.9, the same toolchain emits slightly different

On 10 October 2014 21:31, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > Sounds like an arm-thumb interworking veneer, generated by the linker... the > real function should be called 'asan_handle_no_return' (with some number of '_' > prefixing it. I don't remember how many get added). It is a veneer which has just a jump and a word after it, which

The llvm compiler can now generated movt/movw instructions to create 32-bit constants. Those new instructions use new relocations. Mach-o uses different numbering for relocations than ELF does. For mach-o, ARM_RELOC_PAIR=1 and ARM_RELOC_HALF=8. You need a newer linker that understands the new relocations. -Nick On Feb 20, 2012, at 5:20 AM, Harel Cain wrote: > Hi all, > > I'm

Hi, For the following code: void foo (); int main () {foo();} llvm emits "bl foo" Then I set foo at a far address in linking: aarch64-linux-gnu-gcc -Wl,--defsym=foo=0x80000000 a.o -o a.exe I got an error from ld: a.c:(.text+0x8): relocation truncated to fit: R_AARCH64_CALL26 against symbol `foo' define in *ABS* section in a.exe The question is: do I

Has anyone managed to get FF 18.0 to work on Centos 5.8? I've been hacking at it, placing a stack of .so files (from Centos 6) into a private directory, then using LD_LIBRARY_PATH to point the system to (in a shellscript that subsequently invokes ff 18) but so far I've not managed to find the right combination. I've moved over libstdc++, all or nearly all the .so files from glib2 and

On 10 October 2014 15:30, Evgeniy Stepanov <eugenis at google.com> wrote: > Could this be some kind of linker-generated compatibility magic? I'm not sure. Searching for "____asan_handle_no_return_veneer" on Google gets me this thread. :) I'm tempted to disable that test on ARM+Linux, since we use EHABI instead of SjLj... At least for now... --renato

Binary compiled on a system with ggc 5.5.0 w/ libstdc++.so.6.0.21 Because the major version is libstdc++.so.6 there shouldn't be any problems running it on CentOS 7 with libstdc++.so.6.0.19, right?

Hello Leslie, I don't know quite what to say as I don't know precisely what your question is? If I am not being precise enough please can you put some explicit questions in? From what I can see in the output, here are some comments. >From your arc mapfiles it looks like that in the output both linker's have given the .text output section the correct base address given the

Hello, Renato > While Clang doesn’t include the TARGET2 relocation information, and that > mess up cross-linking. Is there any documentation for this stuff? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello Leslie, The errors coming from the gnu assembler are due to the file being assembled in Arm state, to get rid of the errors you'll either need to put a .thumb directive in the file, or pass -mthumb to the assembler via arm-linux-gnu-gcc -Wa,-mthumb (I think). I'm not able to explain what you are seeing in your print out as it doesn't quite match the map file. Looking at your

Hello, I'm working on an LLVM backend for an experimental microprocessor. Work is going on nicely, and I've until now found the answer to all my questions directly in the LLVM source code, or in the documentation. However, I'm having problems with the AsmBackend class and the handling of fixups. The processor I'm working with has a single conditional branch instruction, JCC,

Dear LLVMers, Here is the current, tentative schedule for LLVM 1.5: 1. We are hoping to have all relevant features and bug fixes into mainline CVS by Friday of this week. For those of you with commit access, please plan to have all of your changes for LLVM 1.5 committed by 9 am (CST) this Friday. If you need more time, please email the list. 2. On Friday, I will be making the 1.5 release

On Oct 7, 2013, at 5:15 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Oct 7, 2013 at 4:02 PM, Nick Kledzik <kledzik at apple.com> wrote: > But is has lots that a linker does not need. For instance, the line/column number does not make sense for a linker. > > Really? Gold has errors that mention lines and columns. It gets them by querying the debug

Hi CentOS, I just completed the yum update to 4.2, hoping to get included with libstdc++.so.6(GLIBCXX_3.4.4) for the x86_64. I need the libs to run cinelerra: [ryan at dorje]# cinelerra cinelerra: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.4' not found (required by cinelerra) An: "rpm -q -i --provides -l libstdc++-3.4.4-2" returns: (A bunch of stuff....)

On Mon, Oct 7, 2013 at 4:02 PM, Nick Kledzik <kledzik at apple.com> wrote: > But is has lots that a linker does not need. For instance, the > line/column number does not make sense for a linker. > Really? Gold has errors that mention lines and columns. It gets them by querying the debug information for file, line, and column. There may be examples of this, but I don't think

Hello all, John Criswell wrote on Wednesday, 11 May 2005: > If other developers (especially those for platforms which we don't have > here at UIUC) could test the release branch, we would be most > appreciative. I will send out another email detailing when the release > branch is finished and how to get it out of CVS. I've just tried building CVS/HEAD of llvm using gcc 4.0.0

I am trying to compile an application on a CentOS 5.0 64-bit machine that gives me the error: /usr/local/bin/myprog: /usr/lib64/libstdc++: version `GLIBXX.3.4.9' not found (required by /usr/local/bin/myprog) I have gcc 4.2.3. I've performed a yum install compat-* and glibc* What am I missing? Thanks. Scott

Hi Jonas, > here is a patch to add Thumb call relocation to the dynamic linker. I would be happy if you could commit it to the SVN. Thanks very much for working on this. It looks like a good starting-point, but there are a couple of issues with the patch at the moment. First, it only handles RelValue up to 22 bits (depending on how you count) in size. But on ARMv6T2 onwards the J1 and J2