search for: shf_exclud

> Given how ELF works I would expect an unknown section to simply end up > in the output, but we can use SHF_EXCLUDE to avoid that. Yes, gold currently treats unknown section types pretty much the same as PROGBITS sections. The SHF_ALLOCATE and SHF_EXCLUDE flags would control where and whether the section goes into the output file. Another thing that we need to work out is the link order. The link order is bas...

...mains unanswered is the encoding. Do we go forward with the abuse of the ELF notes or do is there enough confidence that adding a new section type shouldn’t break compatibility with older linkers? Given how ELF works I would expect an unknown section to simply end up in the output, but we can use SHF_EXCLUDE to avoid that. So +1 for a new section type. Cheers, Rafael

On Fri, Jan 12, 2018 at 5:56 PM, Cary Coutant via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Given how ELF works I would expect an unknown section to simply end up > > in the output, but we can use SHF_EXCLUDE to avoid that. > > Yes, gold currently treats unknown section types pretty much the same > as PROGBITS sections. The SHF_ALLOCATE and SHF_EXCLUDE flags would > control where and whether the section goes into the output file. > > Another thing that we need to work out is the link...

...llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Jan 12, 2018 at 5:56 PM, Cary Coutant via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > Given how ELF works I would expect an unknown section to simply end up >> > in the output, but we can use SHF_EXCLUDE to avoid that. >> >> Yes, gold currently treats unknown section types pretty much the same >> as PROGBITS sections. The SHF_ALLOCATE and SHF_EXCLUDE flags would >> control where and whether the section goes into the output file. >> >> Another thing that we need...

> On Jan 9, 2018, at 2:32 AM, James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > > By my understanding, the proposal is that the user input looks something like: > > #pragma linker_directive("lib", "m") > > which is passed essentially as is to the linker, i.e. the directive payload is a pair of strings, the first being "lib", the

...re, would tie source code to the vagaries of particular linkers. I don't see much value in supporting other linker operations so I suggest that the binary representation be a mergable string section (SHF_MERGE, SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the output). The compiler can form this section by concatenating the arguments of the "comment lib" pragmas in the order they are encountered. Partial (-r, -Ur) links can be handled by concatenating .autolink sections with the normal mergeable stri...

...hand written assembly code. >> >> *Changes Needed :-* >> >> The change that I am trying to propose is the compiler emits a section, >> called (*.safe_sections) *that contains section indices on what sections >> are safe. >> >> The section would have a SHF_EXCLUDE flag, to prevent other linkers from >> consuming this section and making it to the output file. >> >> Data structure for this :- >> >> .safe_sections >> <total size> >> <section index> <boolean flag -- safe/unsafe> >> ... >> ....

...xamples of unsafe sections are, hand written assembly code. > > *Changes Needed :-* > > The change that I am trying to propose is the compiler emits a section, > called (*.safe_sections) *that contains section indices on what sections > are safe. > > The section would have a SHF_EXCLUDE flag, to prevent other linkers from > consuming this section and making it to the output file. > > Data structure for this :- > > .safe_sections > <total size> > <section index> <boolean flag -- safe/unsafe> > ... > ... > > > *Advantages > *...

..., code generated by compilers. Examples of unsafe sections are, hand written assembly code. _*Changes Needed :-*_ The change that I am trying to propose is the compiler emits a section, called (*.safe_sections) *that contains section indices on what sections are safe. The section would have a SHF_EXCLUDE flag, to prevent other linkers from consuming this section and making it to the output file. Data structure for this :- .safe_sections <total size> <section index> <boolean flag -- safe/unsafe> ... ... *_Advantages_ *There are advantages that the atoms within a safe section...

...nges Needed :-* >>> >>> >>> The change that I am trying to propose is the compiler emits a section, >>> called (*.safe_sections) *that contains section indices on what sections >>> >>> are safe. >>> >>> The section would have a SHF_EXCLUDE flag, to prevent other linkers from >>> consuming this section and making it to the output file. >>> >>> Data structure for this :- >>> >>> .safe_sections >>> <total size> >>> <section index> <boolean flag -- safe/unsafe...

...>>>> >>>> The change that I am trying to propose is the compiler emits a section, >>>> called (*.safe_sections) *that contains section indices on what sections >>>> >>>> are safe. >>>> >>>> The section would have a SHF_EXCLUDE flag, to prevent other linkers from >>>> consuming this section and making it to the output file. >>>> >>>> Data structure for this :- >>>> >>>> .safe_sections >>>> <total size> >>>> <section index> &lt...

Hello llvm\lld, The autlolink feature in swift appends a section to the obj files (.swift1_autolink_entries) that is later need to determine what t link against in the final linked binary. I am trying to get rid of these section in the final linked binary at link time. I understand this could be done with (llvm-objcopy --remove-section=.swift1_autolink_entries) but would like have the linker

...ange that I am trying to propose is the compiler emits a section, >>>>> called (*.safe_sections) *that contains section indices on what >>>>> sections >>>>> >>>>> are safe. >>>>> >>>>> The section would have a SHF_EXCLUDE flag, to prevent other linkers >>>>> from >>>>> consuming this section and making it to the output file. >>>>> >>>>> Data structure for this :- >>>>> >>>>> .safe_sections >>>>> <total size&g...

...code to the vagaries of particular linkers. I > don't see much value in supporting other linker operations so I suggest > that the binary representation be a mergable string section (SHF_MERGE, > SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK > (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the > output). The compiler can form this section by concatenating the arguments > of the "comment lib" pragmas in the order they are encountered. Partial > (-r, -Ur) links can be handled by concatenating .autolink sections with the > n...

...aries of particular linkers. I >> don't see much value in supporting other linker operations so I suggest >> that the binary representation be a mergable string section (SHF_MERGE, >> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the >> output). The compiler can form this section by concatenating the arguments >> of the "comment lib" pragmas in the order they are encountered. Partial >> (-r, -Ur) links can be handled by concatenating .autolink sections wit...

...aries of particular linkers. I >> don't see much value in supporting other linker operations so I suggest >> that the binary representation be a mergable string section (SHF_MERGE, >> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the >> output). The compiler can form this section by concatenating the arguments >> of the "comment lib" pragmas in the order they are encountered. Partial >> (-r, -Ur) links can be handled by concatenating .autolink sections wit...

...gt;>>> don't see much value in supporting other linker operations so I suggest >>>> that the binary representation be a mergable string section (SHF_MERGE, >>>> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >>>> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the >>>> output). The compiler can form this section by concatenating the arguments >>>> of the "comment lib" pragmas in the order they are encountered. Partial >>>> (-r, -Ur) links can be handled by concatenatin...

...t see much value in supporting other linker operations so I suggest >>>>>> that the binary representation be a mergable string section (SHF_MERGE, >>>>>> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >>>>>> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the >>>>>> output). The compiler can form this section by concatenating the arguments >>>>>> of the "comment lib" pragmas in the order they are encountered. Partial >>>>>> (-r, -Ur) links can be...

...lar linkers. I >>> don't see much value in supporting other linker operations so I suggest >>> that the binary representation be a mergable string section (SHF_MERGE, >>> SHF_STRINGS), called .autolink, with custom type SHT_LLVM_AUTOLINK >>> (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents appearing in the >>> output). The compiler can form this section by concatenating the arguments >>> of the "comment lib" pragmas in the order they are encountered. Partial >>> (-r, -Ur) links can be handled by concatenating .autolink...

...orting other linker operations so I >>>>>>>> suggest that the binary representation be a mergable string section >>>>>>>> (SHF_MERGE, SHF_STRINGS), called .autolink, with custom type >>>>>>>> SHT_LLVM_AUTOLINK (0x6fff4c04), and SHF_EXCLUDE set (to avoid the contents >>>>>>>> appearing in the output). The compiler can form this section by >>>>>>>> concatenating the arguments of the "comment lib" pragmas in the order they >>>>>>>> are encountered. Partia...