Can it be tested with a test case?
0.5% may not sound a lot, but that's already a helpful amount for some systems, where you have to constantly make tradeoffs that sacrifices some functionalities to free up memory.
Another data point: Sorting the data section for Chrome on Android, data section dirty pages went down from 6308KB to 6280KB (arm32).
Without warn-once option on this example lld prints 20 error messages (-O2 optimization while making object file), with warn-once option it prints just one error message, so if we have similar code in many places this option might be useful.
I think this is a good change, and I agree with you that we don't need to test each alias.
Speaking of the --help message, I found there are other weird stuff there. The options in the --help message are categorized as "Color Options", "General options" and "Generic Options". There is only one option under the "Color Options" category, which is --color. Most options are under "General Options". --help and --version are under "Generic Options". Frankly, these categories doesn't make sense at all to me. (what's the difference between "Generic" and "General"?)
Maybe we should remove the categories and display all options just asciibetically.
Thu, Jan 17
This is probably fine.
I added a requested test showing how -all-headers now dumps the archive headers.
(and removed the old test since the new one covers the added functionality).
Thanks for the answers, James. LGTM.
This patch only moves the code and renames the few methods. No other changes were performed.
Wed, Jan 16
The code change looks good to me, but I'd like a bit more testing, if it's okay. I assume that the output is something like the following for each archive member in turn:
but I don't see anything showing that we're printing things that way (instead of printing all archive headers, then all file headers etc): we should have a test for that.
I think it is good. My comments are below (please wait for Rui's ones though, he might have different opinions I guess).
OK, I have no more comments.
Although I don't want to condone checking things in without a test case, given that the fix is obvious and that testing it is non-trivial, I think it's fine to check this in as is.
Tue, Jan 15
Given the following external comment, can this be closed?
Mon, Jan 14
Yep, MSVS2017 works fine here for me too. Thanks, Pavel! I am abandoning it.
I ended up with the following test case:
- Addressed review comments.
Sat, Jan 12
Fri, Jan 11
I guess it should be possible to trigger this from dotest tests via pexpect. I know we try to avoid it, but given that this is specifically testing terminal interaction, using it here seems appropriate.
Thu, Jan 10
I don't think we need a detailed benchmark for other targets, as how programs use .bss (and in general other parts of data sections) doesn't depend too much on targets.
How mature is this implementation of MSP support? I'd like to add a note to the release notes for the next major release.
And I believe you didn't really have to rush to submit; this is a good patch, so just relax and wait for a little for others to review it as well.
I'll try to switch to MSVS 2017 and recheck this.
BTW, I've been compiling lldb with VS2017 and haven't run into this issue. Also, with the imminent release of VS2019, I expect someone will soon start a thread proposing to drop VS2015, so you might be better of switching to a newer compiler. (But I don't have a problem with checking this in while we still officially support this compiler.)
@grimar Thank you for the review. Could you please commit this change?
I am pretty sure we can land this because having a patch on a review for about a year is always a terrible thing. My comments are inline.
Overall looks good to me. Comments are inlined.
I think this should be landed because at least it simplifies the code. Ping.
"Android Go team (a project to make Android work better on memory and
CPU-contrained devices) found that this heuristics achieves better
memory write locality,"