similar to: Handling of section vs global name conflicts

So, we emit both a global symbol for the global variable, and a local symbol for the section, with the same name? This would need to be fixed both in the integrated assembler and in GAS. Is it even allowed? What would the symbol references bind to, when both symbols are defined? On Mon, Mar 21, 2016 at 7:55 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > The correct fix is

On Fri, Mar 18, 2016 at 01:25:17PM -0700, Evgenii Stepanov via llvm-dev wrote: > Another option is to allow the conflict, and make the global always > override the section symbol. This is easy to do in the integrated > assembler, but it appears that GAS simply does not work this way. Don't we have a similar case for STT_FILE already? Joerg

On Fri, Oct 7, 2016 at 2:48 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com> wrote: > On Fri, Oct 7, 2016 at 2:28 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > On Fri, Oct 7, 2016 at 1:55 PM, Evgenii Stepanov < > eugeni.stepanov at gmail.com> > > wrote: > >> > >> On Fri, Oct 7, 2016 at 1:22 PM, Peter Collingbourne <peter

On Fri, Oct 7, 2016 at 1:55 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com> wrote: > On Fri, Oct 7, 2016 at 1:22 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > On Fri, Oct 7, 2016 at 12:20 PM, Evgenii Stepanov > > <eugeni.stepanov at gmail.com> wrote: > >> > >> I've tried implementing some of the alternatives mentioned in

> -----Original Message----- > From: Evgenii Stepanov [mailto:eugeni.stepanov at gmail.com] > Sent: Wednesday, December 07, 2016 4:51 PM > To: Kostya Serebryany > Cc: Robinson, Paul; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Debug Locations for Optimized Code > > In fact, we are already using "parallel" debug info. Frame layout > descriptions encode

Evgenii Stepanov <eugeni.stepanov at gmail.com> writes: > See https://reviews.llvm.org/D51364 - a very similar bug was > introduced by a compiler-rt change and then fixed by a revert. Ok, so what do we do about this? D50940 seems to have introduced the problem but it was reverted. The "tentative fix" in D51364 was abandoned but it's not clear to me why (maybe because

Hi Evgenii, I was wondering what the status is of your work to attach "internal_linkage" to methods of standard library classes in libc++. The following piece of code doesn't link because a symbol (string::empty) is undefined and it sounds like your work might fix the linkage error I'm seeing. $ cat test1.cpp #include <string> #include <functional> int main() {

I think that absolute atoms will need something similar to, "contentType" added. SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type of symbols caused it to be created. To that end I added a contentType method to AbsoluteAtom and sprinkled changes around to

Hi Evgenii, I have one question about this (planned) change: what if a function is not inlined? The linker will not ODR merge them with this change, which isn’t great. What makes “internal” linkage more desirable than "linkonce_odr + visibility hidden"? — Mehdi > On Jul 12, 2016, at 6:16 PM, Evgenii Stepanov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi,

This commit has added __hwasan_memset to compiler-rt: commit 749bd83b08b7239f5d18c4e3095183919c68eb30 Author: Eugene Leviant <eleviant at accesssoftek.com> Date: Thu Dec 20 09:10:03 2018 +0000 [HWASAN] Add support for memory intrinsics This is patch complements D55117 implementing __hwasan_mem* functions in runtime Differential revision: https://reviews.llvm.org/D55554

It's a test for the new interceptor for prlimit. It could be disabled with __GLIBC_PREREQ for 2.13+. On Fri, Aug 19, 2016 at 5:16 PM, Hans Wennborg <hans at chromium.org> wrote: > +Evgenii for msan. > > I suspect the community simply doesn't keep track of what glibc > version is required :-/ > > On Fri, Aug 19, 2016 at 5:10 PM, Brian Cain <brian.cain at

On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: > > I think that absolute atoms will need something similar to, "contentType" added. > > SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type of symbols caused it to be created. To that end I added a

With respect only to '__attribute__((internal_linkage))', not 'nodebug' and other parts of this topic; does hiding "some" members and not others not introduce a violation of the ODR because some members of the class as it appears in one translation unit are not the same actual definitions as the apparently "same" members of the class in another translation unit?

On Tue, May 23, 2017 at 4:39 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com > wrote: > On Tue, May 16, 2017 at 4:33 PM, Evgenii Stepanov > <eugeni.stepanov at gmail.com> wrote: > > On Mon, May 15, 2017 at 6:44 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> Thanks for sending this out. A few comments below. > >> > >> On

On Fri, Oct 7, 2016 at 12:20 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com > wrote: > I've tried implementing some of the alternatives mentioned in this > thread, and so far I like this syntax the most: > > i32 reloc (29, void ()* @f, 3925868544) > ; 29 = 0x1d = R_ARM_JUMP24 > ; 3925868544 = 0xea000000 > > Note the zeroes in the relocated data instead of

On 10/15/12 12:01, Nick Kledzik wrote: > > On Oct 15, 2012, at 8:08 AM, Sidney Manning wrote: >> >> I think that absolute atoms will need something similar to, "contentType" added. >> >> SHN_ABS symbols can have different types, STT_OBJECT, STT_FILE and maybe others. In order for the writer to tell it must have a way to reach back and ask the atom what type

Hi Nick, The object file already has the information that when its STT_FILE and the symbol name is the name of the translation unit already. I dont think the linker has to add a absolute symbol by figuring out the translation unit. Shankar Easwaran On Mon, Oct 15, 2012 at 6:07 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Oct 15, 2012, at 4:00 PM, Sid Manning wrote: >

Thanks. From the debugging I've done so far it looks like it could be another 32-bit big-endian specific bug. It seems to be segfaulting in the memset() in allocate_stack.c (from glib) because given stack pointer is null. I'm guessing this is because it read the wrong half of a 64-bit value somewhere but I haven't identified where it goes wrong. ________________________________________

On Mon, May 15, 2017 at 6:44 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Thanks for sending this out. A few comments below. > > On Mon, May 15, 2017 at 5:17 PM, Evgenii Stepanov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> this is a proposal for the implementation of CFI-icall [1] with ThinLTO. >> >>

clang revision is good, but the kernel is probably too new. Evgenii can comment on that. On Sat, Sep 12, 2015 at 3:23 PM, Greg Stark <stark at mit.edu> wrote: > On Sat, Sep 12, 2015 at 11:22 PM, Greg Stark <stark at mit.edu> wrote: > > Checked out a few days ago. It looks like r246697. I suppose I could > > try updating and rebuilding. > > Sorry, svn log in the