Address feedback + use option 2

Not meant as a commit for submitting, but wanted to poll the audience on what pattern we'd like to use with threadPool. We essentially have three options here:

• Option 1 - continue using parallelForEach methods
• Option 2 - Re-use our declared class level threadPool, but areas where we only want to wait on a subset of threads, we have to re-implement the fork-join model by declaring some vector and waiting on those threads that are pushed back to the vector (See L1040-1050)
• Option 3 - Declare class-level and method-level threadPools. Simpifies the for loop from Option 2, but might be harder to manage since we now have to control N number of threadPools with a potential of N different concurrency settings. (See L1103-1115)

Show two different ways of using threadPool

Looks cool, but have you tried optimizing the map writing code a bit first? IIRC it's fairly unoptimized.

Use threadpool

I'll admit your suggestion is clever, but I think it sacrifices on readability. How would something like this be modeled in the parallelForEach statement?

std::async(func1);
func2();
std::async(func3);
func4();

Do you have a source for this?

I'm assuming writeOutputFile takes longer than writeMapAsync anyway

Addressing nits

format...

Update to use sizeof() instead of hard-coded number

Sweet! LG

Probably should look at the failing tests. Seems to be related to your changes. [EDIT] - looks like it's fixed but my comment below still stands.

s/warn-no/no-warn

Minor nits and stuff. Overall, generally looks good

Include both pos and neg form of the warning, default to neg

but I'd probably also add a --warn-dylib-install-name to override the no form

In D113241#3132635, @oontvoo wrote:

In D113241#3132610, @thevinster wrote:

Gucci.

👜 ???

Gucci.

Use dedicated warning instead of umbrella

Nice find!

Introduce --warn-strict flag to enable custom warnings for LLD

Maybe we should instead have a flag to disable the warning?

OTOH, SegmentCommand is not overloaded, and used only once. Nlist is not overloaded, and isn't even a header but rather an element in a vector.

I'm a big fan of the variable names switching from s/subsections/sections, s/subsectionMap/subsections. It's clearer to me that there are layers whereas the original subsections->subsectionMap layer is not as easily decipherable. Section->SectionHeader makes sense to me, but I would like it if we had some consistency, which means also renaming SegmentCommand->SegmentCommandHeader, NList->NListHeader, etc.

I agree with jhenderson@ here. I'm not sure why we want to error on this when it's only warning for cctools libtool. This is a backwards incompatible change for those who want to do a drop in replacement of the tool.

Title should also be more specific. "Refactor code" is too generic and doesn't say much about what you are introducing here and why it's needed.

nit feedback

@sheredom Following up on here. Any plans to migrate off the old MachO port over to the new port? I would also love to learn more about what some of the problems are for migrating over to the new MachO port. Part of doing this is also out of selfish reasons as it's been messing up with my IDE and harder for newer devs to ramp up on the new LLD for Mach-O.

I only reviewed the mechanical changes as I'm not too familiar with the functional changes. I'll let someone more experienced comment on that.

Thanks! This seems to check out with the stack trace line that I was seeing.

Lint

Fix minor nits on tests

Address feedback

Looks pretty good to me, other than the comment about the casting.

use for range loop

In D106128#2890061, @int3 wrote:

Fix looks good but can we figure out how it was happening in the first place? I would guess that we were running optimizeOpcodes on an empty vector, but I'm not sure how that would happen in the given test...

Fixing ASAN

Add comments for clarity and address minor comments

In D106128#2888416, @int3 wrote:

one nit about the commit title / description: there are lots of opcodes with immediates, I think it would be clearer to mention DO_BIND_ADD_ADDR_IMM_SCALED specifically in the title. Also "Implement pass 3 of bind opcodes from ld64" should be followed by a short description of what pass 3 does -- we shouldn't expect future readers to have to look it up :)

Address more comments