similar to: [LLVMdev] opinions on turning on encoding info by default in -S

On Dec 14, 2010, at 9:37 PM, Chris Lattner wrote: > On targets that fully support MC for encoding (today that means X86, hopefully ARM will be done soon), llc has a "-show-mc-encoding" option that can be used to dump out the encodings for every instruction. If you're using clang, this can be accessed with the (intentionally) hidden -mllvm option like so: > > $ clang t.c

Hi I am executing following steps to convert assembly to object code. llc -march=x86-64 -filetype=asm input.ll -o input.s g++ -g -c -o input.s --input.o inshort ll --> llc --> .s -->g++ -->obj original source was something like this { printf(" **** %s ****",str); } input.s turn out to be movq .str at GOTPCREL(%rip),%rdi movq .str.1 at GOTPCREL(%rip),%rsi xorl

Bill, ooops, yes, I described the meaning of "throw(A)" backwards, but I still think my example shows why you cannot merge LandingpadInst while inlining because multiple filter-lists on a LandingpadInst don't make sense. Perhaps I'm reading your original spec wrong, perhaps I'm mis-reading Duncan's emails, but I read them to mean that your syntax supports

Hi Mahesh, On 23 April 2018 at 10:51, Mahesh Attarde via llvm-dev <llvm-dev at lists.llvm.org> wrote: > movq .str at GOTPCREL(%rip),%rdi > movq .str.1 at GOTPCREL(%rip),%rsi That's quite strange. You wouldn't normally expect to access a constant string via the GOT. It looks like LLVM has decided to put the symbols in an odd section, so it'd be a good idea to make sure

On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rostedt at goodmis.org> wrote: > On Wed, 4 Oct 2017 14:19:56 -0700 > Thomas Garnier <thgarnie at google.com> wrote: > >> When using -fPIE/PIC with function tracing, the compiler generates a >> call through the GOT (call *__fentry__ at GOTPCREL). This instruction >> takes 6 bytes instead of 5 on the usual

On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rostedt at goodmis.org> wrote: > On Wed, 4 Oct 2017 14:19:56 -0700 > Thomas Garnier <thgarnie at google.com> wrote: > >> When using -fPIE/PIC with function tracing, the compiler generates a >> call through the GOT (call *__fentry__ at GOTPCREL). This instruction >> takes 6 bytes instead of 5 on the usual

Dear Mr. Northover, Thank you for the quick reply. You are correct about the address-mode operands :) . I guess an important detail left out was that the basic block (call it A) that wants to calculate the address of the target stationary trampoline basic block (call it B) will be moved around in memory during run-time. Our earlier solution, before the feature was implemented to move around (A)

On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > When using -fPIE/PIC with function tracing, the compiler generates a > call through the GOT (call *__fentry__ at GOTPCREL). This instruction > takes 6 bytes instead of 5 on the usual relative call. > > If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop > so ftrace can handle the previous 5-bytes as before.

On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > When using -fPIE/PIC with function tracing, the compiler generates a > call through the GOT (call *__fentry__ at GOTPCREL). This instruction > takes 6 bytes instead of 5 on the usual relative call. > > If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop > so ftrace can handle the previous 5-bytes as before.

On Thu, Aug 3, 2017 at 6:19 PM, Tim Northover <t.p.northover at gmail.com> wrote: > 2017-08-03 8:58 GMT-07:00 Johan Engelen via llvm-dev < > llvm-dev at lists.llvm.org>: > > The error is gone after removing (or reducing) the alignment of `%a`. > This > > makes me believe that our inline asm syntax is correct to add an offset > to a > > pointer: "

On Tue, Oct 25, 2016 at 1:48 PM, Rafael Espíndola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > So, for the declaration, do you expect to know the value? If not just > a declaration to a GlobalVariable should be sufficient. > No, the value will be discovered at link time, but we want instruction selection to treat the symbol as an immediate, not a GlobalAddress that will

Hi Jay - I see the slow, small accesses using an older clang [Apple LLVM version 7.0.0 (clang-700.1.76)], but this looks fixed on trunk. I made a change that comes into play if you don't specify a particular CPU: http://llvm.org/viewvc/llvm-project?view=revision&revision=245950 $ ./clang -O1 -mavx copy.c -S -o - ... movslq %edi, %rax movq _spr_dynamic at GOTPCREL(%rip),

On Mon, Apr 01, 2013 at 03:49:14PM -0700, Peter Collingbourne wrote: > On Thu, Mar 21, 2013 at 02:12:27PM +0900, Joerg Sonnenberger wrote: > > On Wed, Mar 20, 2013 at 02:22:47PM -0700, Peter Collingbourne wrote: > > > I am trying to compile a dynamic loader using LLVM. Part of the IR > > > for this loader looks like this: > > > > > > @_rtld_local =

On Thu, May 24, 2018 at 1:16 PM Steven Rostedt <rostedt at goodmis.org> wrote: > On Thu, 24 May 2018 13:40:24 +0200 > Petr Mladek <pmladek at suse.com> wrote: > > On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > > > When using -fPIE/PIC with function tracing, the compiler generates a > > > call through the GOT (call *__fentry__ at GOTPCREL). This

On Thu, Mar 21, 2013 at 02:12:27PM +0900, Joerg Sonnenberger wrote: > On Wed, Mar 20, 2013 at 02:22:47PM -0700, Peter Collingbourne wrote: > > I am trying to compile a dynamic loader using LLVM. Part of the IR > > for this loader looks like this: > > > > @_rtld_local = hidden alias %struct.rtld_global* @_rtld_global > > @_rtld_global = unnamed_addr global

Hello everyone, As part of my quest to add TLS relocation support to MCJIT, I've been taking a closer look at the GOT implementation in RuntimeDyldELF and I believe that is not valid as currently implemented. In particular, I am wondering about the multiple GOT handling support introduced in r192020. If I understand correctly this can make code reuse the GOT table entry in a different object

On Tue, Oct 25, 2016 at 5:49 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > >>> @foo = globalconst i32 42 > >>> > >>> > >>> This is equivalent to writing "foo = 42" in assembly? > >> > >> > >> Yes. > > > > > > Back in the day the idea was to use an alias whose ConstantExpr

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

On Mar 19, 2008, at 2:03 PM, Török Edwin wrote: > > What is kext64, and how do I disable it? Comes from: APPLE_LOCAL='APPLE LOCAL libcc_kext' \ MULTILIBS="`$(GCC_FOR_TARGET) --print-multi-lib` static;@static at fno-pic kext;@Dmal loc=kern_os_malloc at Dfree=kern_os_free at DLIBCC_KEXT@static at fno-pic@fno- exceptions at fno-non-ca

Bill Wendling wrote: > On Wed, Mar 19, 2008 at 12:11 PM, Duncan Sands <baldrick at free.fr> wrote: > >> Hi Bill, thanks for fixing it. >> >> > No prob! :-) I can't build llvm-gcc4.2 on x86-32 Linux. What is kext64, and how do I disable it? (I suppose I don't need it on a 32-bit platform?) ..... ranlib kext/libgcc_eh.a