search for: sht_llvm_addrsig

...guessing it will have its own section > type and format? If it does would it make sense to try and submit this > to the GABI https://groups.google.com/forum/#!forum/generic-abi as it > could be potentially useful for other linkers, for example gold? > Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a sequence of ULEB128-encoded symbol table indexes that are address-significant). I think it makes sense for this to eventually be part of the generic ABI, and I will send a proposal to generic-abi. As I mentioned in my reply to James Knight, I don't think we should block on getti...

...s own section >> type and format? If it does would it make sense to try and submit this >> to the GABI https://groups.google.com/forum/#!forum/generic-abi as it >> could be potentially useful for other linkers, for example gold? >> > > Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a sequence > of ULEB128-encoded symbol table indexes that are address-significant). > > I think it makes sense for this to eventually be part of the generic ABI, > and I will send a proposal to generic-abi. As I mentioned in my reply to > James Knight, I don't think...

...David Spickett. [0] https://bugs.llvm.org/show_bug.cgi?id=39527 [1] https://reviews.llvm.org/D72686 [2] https://reviews.llvm.org/D73469 [3] https://reviews.llvm.org/D72923 [4] https://llvm.org/docs/Extensions.html LLVM Extensions — LLVM 10 documentation<https://llvm.org/docs/Extensions.html> SHT_LLVM_ADDRSIG Section (address-significance table) ¶. This section is used to mark symbols as address-significant, i.e. the address of the symbol is used in a comparison or leaks outside the translation unit. llvm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lis...

...t;> type and format? If it does would it make sense to try and submit this >>> to the GABI https://groups.google.com/forum/#!forum/generic-abi as it >>> could be potentially useful for other linkers, for example gold? >> >> >> Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a sequence >> of ULEB128-encoded symbol table indexes that are address-significant). >> >> I think it makes sense for this to eventually be part of the generic ABI, >> and I will send a proposal to generic-abi. As I mentioned in my reply to >> James Knight...

...t; type and format? If it does would it make sense to try and submit this >>> to the GABI https://groups.google.com/forum/#!forum/generic-abi as it >>> could be potentially useful for other linkers, for example gold? >>> >> >> Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a >> sequence of ULEB128-encoded symbol table indexes that are >> address-significant). >> >> I think it makes sense for this to eventually be part of the generic ABI, >> and I will send a proposal to generic-abi. As I mentioned in my reply to >> Jam...

...t; type and format? If it does would it make sense to try and submit this >>> to the GABI https://groups.google.com/forum/#!forum/generic-abi as it >>> could be potentially useful for other linkers, for example gold? >>> >> >> Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a >> sequence of ULEB128-encoded symbol table indexes that are >> address-significant). >> >> I think it makes sense for this to eventually be part of the generic ABI, >> and I will send a proposal to generic-abi. As I mentioned in my reply to >> Jam...

...If it does would it make sense to try and submit this >>>> to the GABI https://groups.google.com/forum/#!forum/generic-abi as it >>>> could be potentially useful for other linkers, for example gold? >>>> >>> >>> Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a >>> sequence of ULEB128-encoded symbol table indexes that are >>> address-significant). >>> >>> I think it makes sense for this to eventually be part of the generic >>> ABI, and I will send a proposal to generic-abi. As I mentioned in my r...

...If it does would it make sense to try and submit this >>>> to the GABI https://groups.google.com/forum/#!forum/generic-abi as it >>>> could be potentially useful for other linkers, for example gold? >>>> >>> >>> Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a >>> sequence of ULEB128-encoded symbol table indexes that are >>> address-significant). >>> >>> I think it makes sense for this to eventually be part of the generic >>> ABI, and I will send a proposal to generic-abi. As I mentioned in my r...

...make sense to try and submit this >>>>> to the GABI https://groups.google.com/forum/#!forum/generic-abi as it >>>>> could be potentially useful for other linkers, for example gold? >>>>> >>>> >>>> Yes, there is a new section type (SHT_LLVM_ADDRSIG) and format (a >>>> sequence of ULEB128-encoded symbol table indexes that are >>>> address-significant). >>>> >>>> I think it makes sense for this to eventually be part of the generic >>>> ABI, and I will send a proposal to generic-abi. As...

Hello, I think that the approach of using a section to record address significance is a good one. I'm guessing it will have its own section type and format? If it does would it make sense to try and submit this to the GABI https://groups.google.com/forum/#!forum/generic-abi as it could be potentially useful for other linkers, for example gold? Happy to help out with reviews. Peter On 22

Hi all, Context: ld.gold has an --icf=safe flag which is intended to apply ICF only to sections which can be safely merged according to the guarantees provided by the language. It works using a set of heuristics (symbol name matching and relocation scanning). That's not only imprecise but it only works with certain languages and is slow due to the need to demangle symbols and scan