Address feedback + use option 2
- All Stories
- Advanced Search
- Transaction Logs
Dec 15 2021
Dec 14 2021
Dec 13 2021
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
Dec 12 2021
Looks cool, but have you tried optimizing the map writing code a bit first? IIRC it's fairly unoptimized.
Dec 10 2021
Dec 9 2021
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?
Dec 8 2021
I'm assuming writeOutputFile takes longer than writeMapAsync anyway
Nov 30 2021
Nov 23 2021
Update to use sizeof() instead of hard-coded number
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.
Nov 22 2021
Nov 19 2021
Nov 17 2021
Minor nits and stuff. Overall, generally looks good
Nov 16 2021
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
Nov 15 2021
In D113241#3132635, @oontvoo wrote:In D113241#3132610, @thevinster wrote:
Use dedicated warning instead of umbrella
Nov 11 2021
Nov 10 2021
Introduce --warn-strict flag to enable custom warnings for LLD
Nov 9 2021
Maybe we should instead have a flag to disable the warning?
Nov 7 2021
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.
Nov 4 2021
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.
Nov 3 2021
Oct 27 2021
Oct 26 2021
Oct 25 2021
Oct 22 2021
Oct 8 2021
Oct 7 2021
Oct 6 2021
Sep 24 2021
Sep 20 2021
Sep 15 2021
Sep 13 2021
@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.
Sep 8 2021
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.
Sep 4 2021
Thanks! This seems to check out with the stack trace line that I was seeing.
Aug 28 2021
Aug 16 2021
Fix minor nits on tests
Aug 12 2021
Jul 26 2021
Looks pretty good to me, other than the comment about the casting.
Jul 20 2021
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...
Jul 19 2021
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