search for: veneers

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

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

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

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

Hi Tim, You seem to be working around BLX support on ARM, and this linker error has cropped up on our buildbot: http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/3526 llvm/tools/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp:

...;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 appr...

...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 it...

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. &g...

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/do...

...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

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers" <llvm-dev at lists.llvm.org>, "Rafael Espindola" <rafael.espindola at gmail.com> > Sent: Thursday, October 1, 2015 11:46:05 AM > Subject: Re: lld and thread over-subscription > >

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

We have access to an icecast server and i beleve we need to set up a source client. Had a look on the website but docs seem to be mainly concerned with setting up a server. What i really 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,

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 b...