Is this something that would be useful upstream?

Outside the comments @grimar made, LGTM.

Thanks for fixing this. I had recently ran into as well. LGTM.

LGTM.

Test case?

Test case?

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.

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?

I will fix the remaining nits and double-check with gold\ld. Thanks for all the review!

1. Shorten overflow error message.
2. Get rid of MemoryRegion constructors.
3. A few more style changes.

Address more style comments from review feedback.

Address review feedback concerning code style and comments.

1. Finished attribute implementation.

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.

Committed. Thanks for all the review @ruiu. Much appreciated.

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

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

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?

In D27276#625391, @atanasyan wrote:

I'm concerned a bit about the XFAIL mips test. Do you have any estimations when this patch be ready?

@grimar , you are right. The tests lines should be reworked. Thinko on my part. Fixed in r289278. Thanks for pointing this out!

Address review feedback.

Any comments on this one?

Address review feedback:

• Added a few more comments.
• Added test cases.

In D27276#616083, @ruiu wrote:

What is the status of this patch? Is this ready for review?

Other than the one question above, LGTM. I tested this patch with my WIP patch for D27276. Thank you for fixing this.

In D27276#615883, @atanasyan wrote:

FYI

I fixed the problem with _gp symbol in the D27524.

Fixed in rL288768.

Fixed in rL288769.

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

In D26367#612055, @evstupac wrote:

I'm not sure what is "the test-suite".

LGTM. It is constant with my understanding of: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf

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:

Committed. Thanks for the review Rui.

Address review feedback.

This looks good to me too.

Do you have commit rights?

Hmmm, it works on trunk r269671. Not sure what happened before.

I see failure when running the Clang test suite with this patch:

This needs a test case.

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.

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:

Is the ABI documented somewhere public?

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:

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?