search for: addrsig

...: 107281360 (-2%) I measured the object file overhead of these sections in my clang build at 0.08%. That's almost nothing, and I think it's small enough that we can turn it on by default. I've uploaded a patch series for this feature here: https://github.com/pcc/llvm-project/tree/llvm-addrsig I intend to start sending it for review soon. Thanks, -- -- Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180522/0df20999/attachment.html>

..._3 // %bb.2: mov w0, wzr ret .LBB0_3: cmp x8, x9 mov w8, #-1 cneg w0, w8, hs ret .Lfunc_end0: .size f, .Lfunc_end0-f // -- End function .ident "clang version 10.0.0-4ubuntu1 " .section ".note.GNU-stack","", at progbits .addrsig ---8<-------8<-------8<-------8<-------8<-------8<-------8<------- Note the 'ldr x9, [x0]'. At this point there is no guarantee that x0 is a multiple of 8, so why is Clang generating this code? Thanks, -- Jerome

...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...

...sured the object file overhead of these sections in my clang build at > 0.08%. That's almost nothing, and I think it's small enough that we can turn > it on by default. > > I've uploaded a patch series for this feature here: > https://github.com/pcc/llvm-project/tree/llvm-addrsig > I intend to start sending it for review soon. > > Thanks, > -- > -- > Peter > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >

...e abi change have you thought about just going for an array of symbol names or hashes of symbol names where any matching symbol is considered address significant? This would sidestep the problem of keeping the symbol table indices in sync. It would be pessimistic for local symbols if the input SHT_ADDRSIG sections were combined by e.g. "ld -r" but in my experience this should not have too much of an impact on --icf. Might be worth considering in the short term whilst you work on getting gabi acceptance. On Tue, May 22, 2018 at 11:06 PM, Peter Collingbourne via llvm-dev < llvm-dev at l...

...nd 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...

...tion >> 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...

...nd 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...

...s 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...

...sured the object file overhead of these sections in my clang build at > 0.08%. That's almost nothing, and I think it's small enough that we can > turn it on by default. > > I've uploaded a patch series for this feature here: > https://github.com/pcc/llvm-project/tree/llvm-addrsig > I intend to start sending it for review soon. > This sounds like a nice idea, but it'd be great to put in some effort to see if we can get this done in a cross-toolchain collaborative manner, instead of llvm-specific. The need is clearly generic, after all. I'm a bit worried of th...

...s 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...

...e 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...

...pe 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...

...w8, #-1 cneg w0, w8, hs ret .Lfunc_end0: .size f, .Lfunc_end0-f // -- End function .ident "clang version 10.0.0-4ubuntu1 " .section ".note.GNU-stack","", at progbits .addrsig ---8<-------8<-------8<-------8<-------8<-------8<-------8<------- Note the 'ldr x9, [x0]'. At this point there is no guarantee that x0 is a multiple of 8, so why is Clang generating this code? Thanks, -- Jerome _______________________________________________ LLVM Dev...

...retq .Lfunc_end1: .size foo.cold.1, .Lfunc_end1-foo.cold.1 # -- End function .cg_profile foo, L1, 0 .cg_profile foo, foo.cold.1, 7 .section ".note.GNU-stack","", at progbits .addrsig .addrsig_sym foo.cold.1 ``` Thanks, Snehasish Kumar Software Engineer, Google -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200804/21ed1330/attachment-0001.html> -------------- next part -----...

Hi Dimitry, Thanks for your kind response! Thanks for the commit message of Jung's patch, I found that the bug had been fixed in OpenJDK 12 by Zhengyu https://bugs.openjdk.java.net/browse/JDK-8205965 But only backported to 11. So Jung could backport it for OpenJDK 8, thanks a lot! But I argue that the root cause might be in the compiler side, why clang-3.9.1, gcc-6.4.1 couldn't

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1

...retq .Lfunc_end1: .size foo.cold.1, .Lfunc_end1-foo.cold.1 # -- End function .cg_profile foo, L1, 0 .cg_profile foo, foo.cold.1, 7 .section ".note.GNU-stack","", at progbits .addrsig .addrsig_sym foo.cold.1 ``` Thanks, Snehasish Kumar Software Engineer, Google -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200810/9a0bbda1/attachment-0001.html> -------------- next part --...

...gt; >> # -- End function >> >> .cg_profile foo, L1, 0 >> >> .cg_profile foo, foo.cold.1, 7 >> >> .section ".note.GNU-stack","", at progbits >> >> .addrsig >> >> .addrsig_sym foo.cold.1 >> >> ``` >> >> Thanks, >> Snehasish Kumar >> Software Engineer, Google >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org...