search for: alt_entry

...c.me.uk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp#650 Basically you would need to add a hook to the TargetLoweringObjectFile class that allows the object format to control how prefix data is emitted. For Mach-O you would emit a label for a dummy internal symbol, followed by the prefix data and then an alt_entry directive for the function symbol. All other object formats would just emit the prefix data. Peter On Mon, Mar 6, 2017 at 6:16 PM, Moritz Angermann <moritz.angermann at gmail.com > wrote: > Thank you Peter! > > That seems to do the trick! > > $ cat test.s > .section __...

...to main, but we must ensure that > the prefix data is not stripped. > > I’ll have a look at the AsmPrinter. > > Another idea that came to mind is abusing the prologue data. And simply > injecting the prefix data into the prologue data. Then adding the *real* > entry_point as an alt_entry after the prologue data. > > Right now we have. > > .- - - - -. <- main.dsp > | Prefix | > |- - - - -| <- main > | Body | > '- - - - -' > > with Prologue, I believe: > > .- - - - - -. <- main > | Prologue | > |- - - - - -| <- alt_en...

...gmail.com > wrote: > Hi Peter, > > I’ve just experimented with this a bit: > > Say we would end up with the following assembly: > > .section __TEXT,__text > .globl _main > > .long 1 > _main: > inc %eax > ret > > .globl _main.dsp > .alt_entry _main.dsp > What happens if you try ".alt_entry _main" instead? The alt_entry is supposed to be bound to the atom appearing *before* it. > _main.dsp = _main-4 > > .subsections_via_symbols > > (e.g. we inject the .alt_entry after the fact, pointing to the start...

That is in theory what omitting the .subsections_via_symbols directive is supposed 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

....llvm.org> wrote: > > Oh, that's great that it's possible to implement properly, now. Does it actually work for > > It'd be cool if LLVM hooked up its generic section handling support to this feature now, so that the only global symbols that *didn't* get marked as .alt_entry were those at the beginning of what llvm would consider sections. > > Then apple platforms could behave sanely, like all other platforms do, only with -f{function,data}-sections defaulted to on instead of off. What is the advantage of not using -f{function,data}-sections? (i.e. what isn’t s...