Fold inputs into test case

Bail out of function in case of error

Change to error

Again, I'm not sure how to create a test for this one without creating gigantic (> 2 GiB) intermediate object files. The .bss trick won't work here, since we can't have relocations in a .bss section.

Exit with correct error code.

Change to error and add test.

This seems fine as a workaround, though I'm curious about the root cause. Shouldn't there only be conflicts during an update if the update is bringing in pyc files of its own (i.e. if pyc files got committed to svn)?

In D38005#874414, @ruiu wrote:

How about creating huge .bss sections and link them?

I'm not sure how to write a test case for this without creating an object file with a section > 4 GiB (as in that object file will take upwards of 4 GiB on disk). Any ideas?

This fixes my use case; thank you! Waiting for @mclow.lists to confirm it works for him too.

Filed https://bugs.llvm.org/show_bug.cgi?id=34614 about the silent attribute ignoring.

Good point. It looks like clang actually ignores the attributes in that case as well; it just doesn't warn you about it :D

@compnerd, @EricWF and I discussed this a bit on IRC yesterday.

This depends on D37859 for the SOURCE_DIR parameter to llvm_check_source_file_list.

Address comments

@mclow.lists, any final verdict here? I ended up doing this differently for my internal use case, so if you think this isn't generally useful, I'm happy to abandon.

Rebased and tested on Windows again.

Rebase

In D34692#866448, @peter.smith wrote:

Using a std::vector<T> * as a key seems a bit odd to me. IIUC, this vector is a member of InputSection, so we can attach a vector of ThunkSections to InputSections, no?

I've had a think about this a bit more. I think that there is an alternative way to represent ThunkSections and NewThunkSections:

• Store a vector of std::pair<ThunkSection*, uint32_t> where the second member of the pair is the Pass that the ThunkSection was added in.
• When the first Thunk is added to a ThunkSection for the first time we record the Pass.
• When merging Thunks into InputSectionDescription for Pass P we extract the Thunks with size > 0 that were created on Pass P and merge them in. This would require quite a bit of changes to the existing code, for example we'd need to iterate through InputSectionDescriptions and not std::vector<InputSection *> in both createThunks() and mergeThunks(). I'm going to have a go at implementing it but will post as a separate review.

Thanks for all the updates! I tested the updated set of patches against our internal builds, and everything is still looking good.

I'm seeing breakages caused by this as well. Thanks for the fix!

Looks good to me still.

Mostly nits again. The logic looks good to me, though I'm far from being completely familiar with all parts of the existing code.

Since the branch range we're supporting in this patch is ±16 MiB, in theory the thunk sections could be spaced 32 MiB apart instead of 16, with input sections jumping either forward or backward to thunks, correct? I understand it's probably not worth the additional complexity to support that, and I'm not suggesting changing it; I just wanted to confirm my understanding :)

Sorry about all the nits, but I figured I'd try to get all the mechanical issues out of the way, at least :)

This was committed in r311468 and reverted in r311497 because it broke bots. I'm re-opening now that @rafael is back from vacation.

It's really cool that you're getting the filesystem library to work on Windows :)

Ping.

Ping.

Ping.

--dynamic-list and --version-script don't make sense together when building an executable, but the combination can be useful for a shared library. See D36499 for how the two should work together for a shared library.

@mclow.lists does this seem reasonable to you?

@grimar, I believe @ruiu's point was that the real issue is that LLD versions symbols too early, so moving other things upwards in the driver (in this case, the processing of symbols defined in a linker script) to work around the versioning being too early doesn't feel right.

@ruiu, my understanding was that this change would make it less of a hack. It's not terribly difficult to work around as it stands though (you can define your own version of the symbol which got dropped, and in practice that symbol tends to only contain a few instructions); it would be nicer to have the linker handle it, but it's understandable if you think this isn't worthwhile. Thanks for the attempt, @grimar!

In D36713#841478, @mclow.lists wrote:

What's the use case here? What are you trying to accomplish?

There should probably be some documentation for this, but I couldn't think of the right place; the Using libc++ documentation only mentions the actual configuration macros, not their corresponding cmake defines. Any suggestions?

This looks great. Thank you!

SVN r310602.

Thank you!

@peter.smith I believe you meant to link to D35413.

Address comment

Simplify test

Instead of duplicating the test, I can either generalize the existing test to handle both the regular and --export-dynamic cases by replacing hardcoded values with regular expressions where necessary, or just add multiple check prefixes to the existing test and handle the value differences that way. Let me know what's preferable.

For whatever it's worth, I've been using these patches internally on a pretty large codebase, and they've worked really well; I haven't noticed any issues. It sounds like @ikudrin has been using them as well.

r308492

Add comment

Ping. I updated the description based on the email discussion with @majnemer.

Thanks for the explanations @rafael. Everything makes sense now.

(from @rafael's email) Correct, bfd complains. That is why you have to make foo weak, which is annoying.

I'm probably just misunderstanding the discussion here, but bfd complains about multiple definitions if you do .symver x, x@@VER: https://ghostbin.com/paste/c9b4t. Granted, I'm on an old version of binutils, so maybe that's changed?

arc snafu

Correct formatting

Add comment for isDWARF