Is this something that would be useful upstream?
Oct 3 2017
Aug 8 2017
Outside the comments @grimar made, LGTM.
Aug 6 2017
Jul 26 2017
Jul 24 2017
Thanks for fixing this. I had recently ran into as well. LGTM.
Jun 23 2017
Jun 20 2017
Jun 16 2017
Seeing how things grow and de-duplicating as necessary seems like a reasonable strategy to me.
Okay, that makes sense. Thanks to all that explained it.
Jun 15 2017
I having looked through the fine details yet, but one higher level question: I saw the discussions on the mailing list concerning being careful not to go overboard making everything work with multiple object file formats and to start with ELF. That being said, why can't just the ELF functionality of libObject be extended to write? Seems like going that way would make it easier for others to reuse in other tools.
RE: the feature flag statement. Unless we know that this is a win all supported sub-targets (micro-architectures), then it seems like a feature flag would be the way to go, right?
Apr 5 2017
Apr 4 2017
Mar 23 2017
Jan 23 2017
I will fix the remaining nits and double-check with gold\ld. Thanks for all the review!
- Shorten overflow error message.
- Get rid of MemoryRegion constructors.
- A few more style changes.
Address more style comments from review feedback.
Jan 21 2017
Address review feedback concerning code style and comments.
- Finished attribute implementation.
Jan 19 2017
IIUC, the crash is b/c LinkerScript<ELFT>::getSymbolSection has no code to handle the common symbol case. The fix is to use SymbolTableSection<ELFT>::getOutputSection, which does have code for handling commons (and various other kinds). If so, then LGTM.
Jan 9 2017
Committed. Thanks for all the review @ruiu. Much appreciated.
Jan 6 2017
- Address @ruiu's point about using addUndefined. Note that I had to use the long form to control the visibility (for symbols defined in PROVIDE).
- XFAIL of test/ELF/mips-gp-ext.s remains -- this test fails now due to another lld bug. I will look into the other bug after pushing this through.
Jan 5 2017
- Address @ruiu's point about using replaceBody.
- Add XFAIL back to test/ELF/mips-gp-ext.s -- this test fails now due to another lld bug. I will look into the other bug after pushing this through.
Jan 3 2017
Apologies for the delay on this one. @ruiu, if I understand correctly you are suggesting for the unconditional replacement of the symbols in the symbol table. That make sense to me. The latest patch adds a "force create" option to the appropriate symbol table methods. Is that okay?
Dec 18 2016
I'm concerned a bit about the XFAIL mips test. Do you have any estimations when this patch be ready?
Dec 9 2016
@grimar , you are right. The tests lines should be reworked. Thinko on my part. Fixed in r289278. Thanks for pointing this out!
Dec 8 2016
Address review feedback.
Any comments on this one?
Address review feedback:
- Added a few more comments.
- Added test cases.
Dec 7 2016
Other than the one question above, LGTM. I tested this patch with my WIP patch for D27276. Thank you for fixing this.
Dec 6 2016
Fixed in rL288768.
Fixed in rL288769.
Dec 5 2016
Address review feedback about constraining LLVM attribute application.
Would someone mind committing this?
(I am happy to do so myself if no one has the cycles.)
Dec 2 2016
LGTM. It is constant with my understanding of: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
Nov 30 2016
I want to be able to override *any* symbol's value (which is support in GNUnLD, for example). Currently LLD issues multiple definition errors if I say something like:
Nov 23 2016
Nov 22 2016
Committed. Thanks for the review Rui.
Address review feedback.
Nov 21 2016
Jun 28 2016
This looks good to me too.
Jun 2 2016
Do you have commit rights?
May 16 2016
Hmmm, it works on trunk r269671. Not sure what happened before.
I see failure when running the Clang test suite with this patch:
Apr 5 2016
This needs a test case.
Mar 2 2016
I can't speak for the technical changes in this patch, but I will say that I too was experiencing a deadlock on OS X and this patch fixes the problem.
Nov 26 2015
This patch looks good to me with respect to the MSP430 ABI. I did find one other change that needs to be made. Now that R11 is not preserved by the callee it should be marked as clobbered by the call instructions:
Nov 25 2015
Is the ABI documented somewhere public?
Nov 24 2015
Nov 20 2015
It is my understanding as well that -march=armv6 and -march=armv6j are treated the same code gen wise by GCC. However, they do cause different builtin macro to be defined. For example:
Nov 2 2015
I haven't worked through all the logic yet, but this seems like a very specific optimization. How often have you found that it fires in practice? Any benchmark results?