search for: altentry

...to do, but in an experiment I ran a year or two ago I found that the Mach-O linker was still dead stripping on symbol boundaries with this directive omitted. In any case, a more precise approach has more recently (~a few months ago) become possible. There is a relatively new asm directive called .altentry that, as I understand it, tells the linker to disregard a given symbol as a section boundary (LLVM already uses this for aliases pointing into the middle of a global). So what you would do is to use .altentry on the function symbol, with an internal symbol appearing before the prefix data to ensure...

...t in an experiment I ran a year or two ago I found that the Mach-O linker was still dead stripping on symbol boundaries with this directive omitted. > > In any case, a more precise approach has more recently (~a few months ago) become possible. There is a relatively new asm directive called .altentry that, as I understand it, tells the linker to disregard a given symbol as a section boundary (LLVM already uses this for aliases pointing into the middle of a global). So what you would do is to use .altentry on the function symbol, with an internal symbol appearing before the prefix data to ensure...

...ar or two ago I found > that the Mach-O linker was still dead stripping on symbol boundaries with > this directive omitted. > > > > In any case, a more precise approach has more recently (~a few months > ago) become possible. There is a relatively new asm directive called > .altentry that, as I understand it, tells the linker to disregard a given > symbol as a section boundary (LLVM already uses this for aliases pointing > into the middle of a global). So what you would do is to use .altentry on > the function symbol, with an internal symbol appearing before the prefix...

...ago I found > that the Mach-O linker was still dead stripping on symbol boundaries with > this directive omitted. > > > > > > In any case, a more precise approach has more recently (~a few months > ago) become possible. There is a relatively new asm directive called > .altentry that, as I understand it, tells the linker to disregard a given > symbol as a section boundary (LLVM already uses this for aliases pointing > into the middle of a global). So what you would do is to use .altentry on > the function symbol, with an internal symbol appearing before the prefix...

...found that the Mach-O linker was still dead stripping on symbol boundaries > with this directive omitted. > > > > > > > > In any case, a more precise approach has more recently (~a few > months ago) become possible. There is a relatively new asm directive called > .altentry that, as I understand it, tells the linker to disregard a given > symbol as a section boundary (LLVM already uses this for aliases pointing > into the middle of a global). So what you would do is to use .altentry on > the function symbol, with an internal symbol appearing before the prefix...

Hi, I just came across a rather annoying behavior with llvm 3.9. Assuming the following samle code in test.ll: ; Lets have some global int x = 4 @x = global i32 10, align 4 ; and two strings "p = %d\n" for the prefix data, ; as well as "x = %d\n" to print the (global) x value. @.str = private unnamed_addr constant [8 x i8] c"x = %d\0A\00", align 1 @.str2 = private

...e it untenable to keep working in that codebase. In an ideal world, the abstraction could have been fixed, but for various non-technical reasons that ended up not happening (I will not go into more detail about that on the mailing list). Also, interestingly, if you search the mailing list for "altentry", it seems like MachO has added a feature that breaks with the "atom" model as well. So there is some hope that further development on the atom LLD for MachO may fix this. Still, there are other challenges. The experience from LLD/COFF and LLD/ELF means that we now have enough link...

...ep working in that codebase. In an ideal world, the abstraction > could have been fixed, but for various non-technical reasons that > ended up not happening (I will not go into more detail about that on > the mailing list). Also, interestingly, if you search the mailing > list for "altentry", it seems like MachO has added a feature that > breaks with the "atom" model as well. So there is some hope that > further development on the atom LLD for MachO may fix this. Still, > there are other challenges. > The experience from LLD/COFF and LLD/ELF means that we n...

...ep working in that codebase. In an ideal world, the > abstraction could have been fixed, but for various non-technical reasons > that ended up not happening (I will not go into more detail about that on > the mailing list). Also, interestingly, if you search the mailing list for > "altentry", it seems like MachO has added a feature that breaks with the > "atom" model as well. So there is some hope that further development on the > atom LLD for MachO may fix this. Still, there are other challenges. > > > The experience from LLD/COFF and LLD/ELF means that...

On Tue, Dec 13, 2016 at 12:01 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 13, 2016, at 11:51 AM, Rui Ueyama <ruiu at google.com> wrote: > > On Tue, Dec 13, 2016 at 11:37 AM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> On Dec 13, 2016, at 11:30 AM, Rui Ueyama <ruiu at google.com> wrote: >> >> On Tue, Dec

I got the file that was sent to me the other day. Unfortunitly it did not solve my problems. After a lot of hacking I have been able to get release 1.0 to almost compile. I have finally gotten all of the dependancies worked out under OpenBSD 3.2. This next error has me stumped. I can tell that it is looking for a file but have no idea how to create the file. This is the output of the the