similar to: [LLVMdev] Question about llvm/llvm-gcc visibility

Hi, Mark > #pragma GCC visibility push(hidden) In theory - yes. > If so, what are the options I need to set when configuring llvm and > llvm-gcc? Well... No extra options are needed. > I'm able to compile the module with llvm-gcc (with the above pragma > included), but the kernel still rejects the module at load time saying the > module is compiled with PLT/GOT. Visibility

Hi, I'm in the process of migrating from clang5 to clang10. Unfortunately clang10 introduced a negative performance impact. The cause is an increase of PLT entries from this patch (first released in clang7): https://bugs.llvm.org/show_bug.cgi?id=36370 https://reviews.llvm.org/D43383 If I revert that clang patch locally, the additional PLT entries and the performance impact disappear. This

> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Fangrui > Song via llvm-dev > Sent: Thursday, August 20, 2020 10:18 PM > To: Leonard Chan <leonardchan at google.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for > representing function PLT

I do have concerns about the amount of object level modeling that we want to do in the IR though. While it isn't the highest level IR we've managed to mostly avoid these kinds of features/complications in the past. I'm definitely interested in hearing some alternate implementations here and there rather than a full set of constants for relocations. Keeping the IR abstract enough over

On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky at amd.com> wrote: > On 10/11/2017 3:30 PM, Thomas Garnier wrote: >> Changes: >> - patch v1: >> - Simplify ftrace implementation. >> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. >> - rfc v3: >> - Use --emit-relocs instead of -pie to reduce dynamic

On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky at amd.com> wrote: > On 10/11/2017 3:30 PM, Thomas Garnier wrote: >> Changes: >> - patch v1: >> - Simplify ftrace implementation. >> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. >> - rfc v3: >> - Use --emit-relocs instead of -pie to reduce dynamic

Hi Lang, Yeah, I remember this case. Basically what’s happening is that there are relocations for ELF on x86 that use a value that is present in the object image as part of the calculation for the final value that goes in the same location. If you ever find yourself applying relocations for a second time (for instance, because the loaded object location is remapped for out-of-proc execution)

Gurus- Do llvm-gcc or clang provide a way to catch use-after-free types of issues? Thanks, -KC -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090512/0118d2b1/attachment.html>

On Tue, May 12, 2009 at 5:03 PM, Mark A. Lyan <omineo at gmail.com> wrote: > Gurus- > > Do llvm-gcc or clang provide a way to catch use-after-free types of issues? > llvm-gcc and clang don't. But I believe that the static analyzer has facilities for this. http://clang.llvm.org/StaticAnalysis.html -bw

On Wed, Mar 15, 2017 at 2:22 PM, Martin Richtarsky <s at martinien.de> wrote: > Here is the relevant output: > > 0000000000013832 <func()>: > 13832: 55 push %rbp > 13833: 48 89 e5 mov %rsp,%rbp > 13836: 53 push %rbx > 13837: 48 83 ec 18 sub $0x18,%rsp

On 7 June 2016 at 10:54, Shi, Steven <steven.shi at intel.com> wrote: > Hi Rafael, > I finally enable the clang LTO build with small code model and PIE, and my clang LTO Uefi firmware works now. Thank you! But I have one more issue on the clang normal build (without LTO) now. I find the small code model + "-fpie" build option will let clang generate some R_X86_64_GOTPCREL

On 22 May 2013, at 13:23, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Why the private message? If unintentional, please forward this to the list. Ooops, forgot to hit reply-all. Didn't the LLVM lists used to default to reply-to-list behaviour? > So, the JIT is analogous to dlopen, so it should be using general > dynamic and local dynamic models. It is only the

Hi Martin, It's hard to tell what is wrong only with the information. If that is an open-source program, can you give me a link to that so that I can try? If that's a proprietary software you cannot share with me, you might want to produce small reproducible test case. On Thu, Mar 23, 2017 at 1:10 AM, Martin Richtarsky <s at martinien.de> wrote: > Hi Rui, > > fyi I'm

> On Mar 4, 2016, at 2:48 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 29, 2016 at 1:53 PM, < <mailto:>> wrote: > @A_vtable = {i8*, i8*, i32, i32} {0, @A::rtti, @A::f - (@A_vtable + 16), @A::g - (@A_vtable + 16)} > > There's a subtlety about this aspect of the ABI that I should call attention to. The virtual function

The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. #include <stdio.h> int main() { fputs("hi\n", stdout); } The reason is that stdout gets a R_X86_64_PC32 relocation, but is of type Object. The ELF writer can't see this, and assumes all R_X86_64_PC32 relocations in dynamic outputs are to functions

On 9/23/2013 7:07 PM, Nick Kledzik wrote: > On Sep 23, 2013, at 4:52 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. >> >> #include <stdio.h> >> >> int main() { >> fputs("hi\n", stdout); >>

Hi, I wanted to see if there was a way in IR to emit a local alias such that I would get: ``` .type _ZTVSt13bad_exception, at object # @_ZTVSt13bad_exception .globl _ZTVSt13bad_exception _ZTVSt13bad_exception: *.L_ZTVSt13bad_exception:* .long 0 # 0x0 .long (_ZTISt13bad_exception.rtti_proxy-.L_ZTVSt13bad_exception)-8 .long

> -----Original Message----- > From: Fāng-ruì Sòng <maskray at google.com> > Sent: Friday, August 21, 2020 4:04 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: Leonard Chan <leonardchan at google.com>; llvm-dev at lists.llvm.org > Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for > representing function PLT entries > > On Fri, Aug

You present a good case for not using "protected" visibility in ELF, despite it being exactly what it is supposed to mean. >From what http://www.airs.com/blog/archives/307 says, it sounds like the *correctness* issue with protected visibility is because LLVM is doing it wrong -- not an intrinsic property of protected visibility in ELF, or even ELF/x86. The blog says that the compiler

>> Any thoughs? > > I'm now struggling to see how GCC justifies it. What if a different > translation-unit declared those variables in a different order? I also > can't get the same behaviour here, do you have a more complete > command-line? Ah, I see; the translation-unit that does the optimisation needs to have them as a definition (i.e. "= {0}") rather