- User Since
- Jan 18 2017, 9:47 AM (121 w, 6 d)
Thu, May 16
Thu, May 9
Wed, May 1
Tue, Apr 30
Thu, Apr 25
Addressed review comments
I am keen to keep this moving.
Wed, Apr 24
Apr 16 2019
No longer shortening "dependent libraries" to "deplibs" except for the .deplibs section (as this takes up bytes on disk).
Apr 15 2019
LGTM! Thanks for waiting for me to confirm. Comments inline:
Apr 12 2019
Sorry for the delay in replying. I was trying to understand if the upgrade path was important. Comments inline:
Apr 10 2019
Apr 9 2019
I have updated the diff to address review comments. I think we can continue to refine this patch in parallel with discussing the design further (I am not dismissing the concerns raised by @compnerd and @jyknight).
Addressed review comments.
Apr 8 2019
Apr 5 2019
Apr 4 2019
Mar 28 2019
Apologies that I didn't check the information on the original bug. The GDB behaviour does look reasonable, thanks.
Mar 22 2019
<Trying again via phabricator rather than replying on the list.>
Mar 21 2019
Jan 16 2019
I strongly feel that we shouldn't implement this. This will tie groups and --gc-sections together when they are orthogonal features; e.g. COMDAT groups will *also* have to be considered by --gc-sections as a single unit. The ability to strip individual sections form COMDAT groups is an important feature. I will add similar comment to the abi list. I'm surprised that gold implements this behavior, back in 2017 gold and bfd-ld disagreed on this.
Jan 10 2019
Jan 9 2019
The wording of the standard is unfortunate. This has been brought up and clarified (that COMDATs are the only legal groups currently) on the list previously.
There is a relevant discussion about non-COMDAT groups here: https://reviews.llvm.org/D56437.
I agree with Rui. My understanding is that groups in ELF were designed specifically to support C++ templates and inline functions which is why COMDAT groups are the only allowed kind.
Interestingly, I have been having a somewhat related discussion on this review: https://reviews.llvm.org/D53234.
Could the annobin tool use SHF_LINK_ORDER instead?
Dec 21 2018
Nov 28 2018
Nov 26 2018
Trying again... Phabricator didn't like the markup in my last comment attempt.
Nov 16 2018
Oct 31 2018
Hi Aron, I'm interested in reviewing this. Would you mind responding to my comments on https://reviews.llvm.org/D53234 first, as you have based the correctness of this on the correctness of that change?
Sep 5 2018
Thanks for the comments everyone.
Aug 31 2018
Added missing newline at end of test file
Aug 23 2018
Aug 22 2018
Thanks for the detailed reply Peter!
Aug 21 2018
Hi George. Do we actually want this behaviour?
Aug 20 2018
Hi. Sorry to be slow to comment on this.
Aug 2 2018
Jul 23 2018
Jun 28 2018
updated diff to address review comments
Jun 26 2018
Having thought about this I have decided to try to simplify the help text as much as possible to aid maintenance.
Jun 25 2018
Jun 22 2018
Jun 19 2018
I would propose adding the ability to retrieve a unique filtered list of arguments.
Jun 4 2018
May 31 2018
Hi Rui! Thanks for looking at the patch.
Mar 27 2018
Why are extra symbols *in the assembly* a problem? We normally don't print assembly
Hi Rafael. The SN-Linker has the following rule for metadata sections:
Mar 26 2018
LGTM., as long as this doesn't cause the number of symbols to double up?
Jan 19 2018
Dec 22 2017
Addressed review comments
Dec 21 2017
I have reworked this now, see: https://reviews.llvm.org/D41497.