search for: veneer

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 points to a place in memory that had whi...

...movk x8, #:abs_g1_nc:foo movk x8, #:abs_g0_nc:foo ldr x8, [x8] blr x8 or I miss some flag during linking? PS. The above test works fine with arm v7 targart. (clang emits "bl foo" and ld generates veneer) Thanks, Weiming -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140619/f4af6377/attachment.html>

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

...m> 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 mode change is required because there's no "bx (imm)" > instruction. I'm curious as to what changed the behaviour, and from what? bx reg? or non-tail call? If I manage to reproduce it, I'll post back here. cheers, --renato

...eContextEPv+0x88): relocation truncated to fit: R_ARM_THM_JUMP24 against symbol `operator delete(void*)@@GLIBCXX_3.4' defined in .text section in /usr/lib/gcc/arm-linux-gnueabihf/4.8/libstdc++.so If I read the AAELF ABI document correctly, that relocation is used when the linker is building a veneer for under-reaching branches, which seems to be one of your changes (269101), though that was supposed to be MachO only. Do you have any ideas on the issue? cheers, -renato PS: I'm bisecting it right now, but it's self hosted + compiler-rt, so it will take a while. Also, I fear whatever I...

...;m supposing that will work automatically when the output streamer is printing object code and meets a non-code region, so in theory, changing MCELFStreamer accordingly (overriding those functions in there) would take care of data vs. code issue in ELF. Assuming LLVM doesn't generate ARM/Thumb veneers inside the same function (ie. a Thumb function has only Thumb code), Greg could use the EmitDataRegion and EmitDataRegionEnd, with the former saving the state of the current code (Thumb/Arm) and the latter restoring it, by emiting the $d and $a/t respectively. Does it seem like a good initial app...

...d > meets a non-code region, so in theory, changing MCELFStreamer > accordingly (overriding those functions in there) would take care of > data vs. code issue in ELF. Yep. They'll likely be implemented as, effectively, an EmitLabel(). > Assuming LLVM doesn't generate ARM/Thumb veneers inside the same > function (ie. a Thumb function has only Thumb code), Greg could use > the EmitDataRegion and EmitDataRegionEnd, with the former saving the > state of the current code (Thumb/Arm) and the latter restoring it, by > emiting the $d and $a/t respectively. > > Does i...

On Oct 5, 2012, at 12:15 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Greg, > >> Is this a bug? If so, how can I fix it? > > It's somewhere between a bug and a quality-of-implementation issue. > ARM often uses literal pools in the middle of code when it needs to > materialize a large constant (or variable address more likely for >

...egion, so in theory, changing MCELFStreamer >> accordingly (overriding those functions in there) would take care of >> data vs. code issue in ELF. > > Yep. They'll likely be implemented as, effectively, an EmitLabel(). > >> Assuming LLVM doesn't generate ARM/Thumb veneers inside the same >> function (ie. a Thumb function has only Thumb code), Greg could use >> the EmitDataRegion and EmitDataRegionEnd, with the former saving the >> state of the current code (Thumb/Arm) and the latter restoring it, by >> emiting the $d and $a/t respectively. &...

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

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,

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

...version. While its relatively new, it is quickly gaining mind share and it provides lots of features and supports numerous platforms today. For more details you can check out: http://apr.apache.org/. Our use of APR would be limited to the lib/System library. That is, we would provide very thin C++ veneers on top of APR's C interface that match the current lib/System and lib/Support APIs. Since an APR implementation would get lib/System "done" on all our platforms much faster than the current approach, I'd like to know if anyone has any objections. Briefly, here's the upside/d...

...ing MCELFStreamer >>> accordingly (overriding those functions in there) would take care of >>> data vs. code issue in ELF. >> >> Yep. They'll likely be implemented as, effectively, an EmitLabel(). >> >>> Assuming LLVM doesn't generate ARM/Thumb veneers inside the same >>> function (ie. a Thumb function has only Thumb code), Greg could use >>> the EmitDataRegion and EmitDataRegionEnd, with the former saving the >>> state of the current code (Thumb/Arm) and the latter restoring it, by >>> emiting the $d and $a/t...

...m the ABI: "The compiler might choose to use only the Thumb ISA in a specific build of a source file. Nonetheless, the relocatable file should be tagged as having been permitted to use the ARM ISA so that a linker can later link it with ARM-state library code and generate ARM-state intra-call veneers if that gives benefit to the executable file. On the other hand, if the user intends code to be executed by both ARM7TDMI and Cortex-M3, the compiler must be constrained to generate only Thumb v1 instructions and the relocatable file should be tagged as not permitted to use the ARM ISA." So,...

Hi Renato, > On 13 November 2010 15:12, Duncan Sands<baldrick at free.fr> wrote: >> I agree that it's limited. As for MC, it will need to handle these strings >> anyway since this is an existing LLVM feature (coming from gcc originally) >> that needs to be supported. > > Do you mean that LLVM-GCC generates build attributes as asm strings in IR? no, I mean

...ARM/mapping-code-model.test lld :: elf/ARM/mapping-symbols.test lld :: elf/ARM/missing-symbol.test lld :: elf/ARM/plt-dynamic.test lld :: elf/ARM/plt-ifunc-interwork.test lld :: elf/ARM/plt-ifunc-mapping.test lld :: elf/ARM/rel-arm-call.test lld :: elf/ARM/rel-arm-jump24-veneer-b.test lld :: elf/ARM/rel-arm-mov.test lld :: elf/ARM/rel-arm-prel31.test lld :: elf/ARM/rel-arm-target1.test lld :: elf/ARM/rel-arm-thm-interwork.test lld :: elf/ARM/undef-lazy-symbol.test lld :: elf/Hexagon/dynlib-data.test lld :: elf/Mips/exe-dynamic.test lld :: e...

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 object Clang is producing. I've opened a bug so that we're aware, and in case anyone sees it again and manage to reproduce, we may be able to either fix i...

...lly want is something that i can use in conjunction with Jack Audio conection Kit. any pointers would be great. If its any help I am using the DeMuDi 1.2.0. Linux distribution. ben -- Ben Edwards - Poole, UK, England WARNING:This email contained partisan views - dont ever accuse me of using the veneer of objectivity If you have a problem emailing me use http://www.gurtlush.org.uk/profiles.php?uid=4 (email address this email is sent from may be defunct)

On Sun, 12 Sep 2004, Reid Spencer wrote: > Our use of APR would be limited to the lib/System library. That is, we > would provide very thin C++ veneers on top of APR's C interface that > match the current lib/System and lib/Support APIs. I think that optionally supporting a an APR interface would not be a bad idea of obscure platforms, but LLVM should not depend on it. I think that all of the major platforms should be natively supported...