search for: strippabl

...ped when unknown. > > Anyways, that's my only real comment about the proposal. I think you need something other than metadata to encode this. I had thought of that too (and having a module-level attribute scheme), but I was surprised when I found out that named metadata wasn't "strippable" from modules. (You can't strip them via the 'opt' command.) Chris assured me that they were meant to stick around... -bw

...> Anyways, that's my only real comment about the proposal. I think you > need something other than metadata to encode this. > > I had thought of that too (and having a module-level attribute scheme), > but I was surprised when I found out that named metadata wasn't > "strippable" from modules. (You can't strip them via the 'opt' command.) I'm not claiming that we have a tool today that will strip named metadata for modules, I'm just claiming that the design of metadata, as Nick explained it to me originally and as he has re-explained it to me re...

On Wed, Jan 18, 2012 at 1:36 PM, Bill Wendling <wendling at apple.com> wrote: > Hello, > > This is a proposal for implementing "module flags". Please take a look at > this and give any feedback you may have. > > Thanks! > -bw > > Module Flags Metadata > I have only one real comment -- this violates the contract and spirit of

Hello Rui, Thanks for your reply. I tried with the keep-section argument and that made the shared library work. Should these sections be kept around by default maybe? -- Tobias On Thu, Oct 17, 2019 at 11:06 AM Rui Ueyama <ruiu at google.com> wrote: > > One thing I noticed is that llvm-strip seemed to remove a .ARM.attributes section. Can you try --keep-section=.ARM.attributes to

...ibutes went away. For LLD we took the position that it was > > > > worth keeping the .ARM.attributes to placate eglibc, as this was more > > > > likely to be encountered 2 years ago. I've not got a strong position > > > > on llvm-strip, in theory it should be strippable from executable and > > > > shared libraries, but there may be a case that eglibc is important > > > > enough to not strip by default. > > > > > > > > Peter > > > > > > > > On Thu, 17 Oct 2019 at 10:16, Tobias Hieta via llvm-d...

The ELF file header isn't always covered by a segment but still affects loading. I think everything else that effects loading/dynamic linking is always covered by a PT_LOAD segment. As evidence this is basically what --strip-sections in llvm-strip and eu-strip do and they produce perfectly runnable binaries. Having a hash of the actual memory map is interesting IMO. Build IDs can't really

...>> >> Anyways, that's my only real comment about the proposal. I think you need something other than metadata to encode this. > > I had thought of that too (and having a module-level attribute scheme), but I was surprised when I found out that named metadata wasn't "strippable" from modules. (You can't strip them via the 'opt' command.) - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120124/866f4087/attachment.html>

...e took the position that it was >> > > > > worth keeping the .ARM.attributes to placate eglibc, as this was more >> > > > > likely to be encountered 2 years ago. I've not got a strong position >> > > > > on llvm-strip, in theory it should be strippable from executable and >> > > > > shared libraries, but there may be a case that eglibc is important >> > > > > enough to not strip by default. >> > > > > >> > > > > Peter >> > > > > >> > > > >...

...at's my only real comment about the proposal. I think > you need something other than metadata to encode this. > > I had thought of that too (and having a module-level attribute > scheme), but I was surprised when I found out that named metadata > wasn't "strippable" from modules. (You can't strip them via the > 'opt' command.) > > > I'm not claiming that we have a tool today that will strip named > metadata for modules, I'm just claiming that the design of metadata, as > Nick explained it to me originally and as...

Hello, This is a proposal for implementing "module flags". Please take a look at this and give any feedback you may have. Thanks! -bw Module Flags Metadata Information about the module as a whole is difficult to convey to LLVM's subsystems. The LLVM IR isn't sufficient to transmit this information. One should instead use the llvm.module.flags named