search for: prefix_data

...prefix data. It would look something like: | Prefix Data ... (variable length) | Prefix Data Length (fixed length [32 bits?]) | Function code .... | ^ function symbol points here (function code) I hope the simple ASCII art makes it through my mail client. To access the data, you do prefix_data = function_ptr - sizeof(prefix_length) - prefix_length Cheers, Jevin

...t; | Prefix Data ... (variable length) | Prefix Data Length (fixed length > [32 bits?]) | Function code .... | > > ^ function symbol points here (function code) > > I hope the simple ASCII art makes it through my mail client. > > To access the data, you do > > prefix_data = function_ptr - sizeof(prefix_length) - prefix_length > > Cheers, > Jevin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > --------...

Hi, I would like to propose that we introduce a mechanism in IR to allow arbitrary data to be stashed before a function body. The purpose of this would be to allow additional data about a function to be looked up via a function pointer. Two use cases come to mind: 1) We'd like to be able to use UBSan to check that the type of the function pointer of an indirect function call matches the

....alt_entry _main.dsp > _main.dsp = _main-4 > > .subsections_via_symbols > > we still get a warning, but it won’t get stripped. At that point however, > we don’t need the .alt_entry > anymore (and can drop the warning). > > Thus, I’d propose that for functions with prefix_data, a second symbol > with .no_dead_strip is emitted > for the prefix data entry point. I don't think that is sufficient. I believe that the linker is allowed to move the function away from the prefix data even if the function is not dead stripped. Peter > Cheers, > Moritz > &...

...in.dsp = _main-4 > > > > .subsections_via_symbols > > > > we still get a warning, but it won’t get stripped. At that point > however, we don’t need the .alt_entry > > anymore (and can drop the warning). > > > > Thus, I’d propose that for functions with prefix_data, a second symbol > with .no_dead_strip is emitted > > for the prefix data entry point. > > > > I don't think that is sufficient. I believe that the linker is allowed > to move the function away from the prefix data even if the function is not > dead stripped. > &gt...

...; > > .subsections_via_symbols > > > > > > we still get a warning, but it won’t get stripped. At that point > however, we don’t need the .alt_entry > > > anymore (and can drop the warning). > > > > > > Thus, I’d propose that for functions with prefix_data, a second symbol > with .no_dead_strip is emitted > > > for the prefix data entry point. > > > > > > I don't think that is sufficient. I believe that the linker is allowed > to move the function away from the prefix data even if the function is not > dead str...

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