Reverted in r369167
Fri, Aug 16
I can't reproduce the test case -- it seems llvm-readelf already prints the NT_GNU_BUILD_ID when I follow the test steps.
We're seeing some compilation timeouts that bisect to the patch (5-10s -> >900s). I'm working on a repro.
Thu, Aug 15
LGTM, no concerns from me once the test is updated
Sounds like you get to claim this as a fix for https://bugs.llvm.org/show_bug.cgi?id=24115 too :)
I don't see anything major left, but please wait for James to take another look
Note that despite being a plain translation from md to rst, git doesn't think these are close enough and shows them as deletion+addition instead of moves.
Did you build these docs locally? (Honestly asking -- I'm wondering if there's something about my local setup that's overly strict, I see doc errors too frequently). I'm getting errors running ninja docs-llvm-html:
Wed, Aug 14
Tue, Aug 13
Did you run ninja docs-llvm-html (or equivalent if not using ninja) when submitting? I'm still seeing this error in trunk.
Mon, Aug 12
The change looks fine to me, although I wasn't able to quickly find the list of section types anywhere to check against. Could you provide me some documentation?
This was already committed to LLVM years ago in rL178679 (+echristo, the committer), but mistakenly removed in rL235863 due to being an unused variable, instead of the right fix, which is clearly the Attributes->Types typo fixed here
- Use const for CoreNote param
Fri, Aug 9
- Use DataExtractor instead of custom logic + remove some now unnecessary template use
- Split up type/description printing
- Add printing for unknown note types
- Clarify comment about generating section data
Just one test that needs fixing, LGTM otherwise:
Can you explain more about the use case? Not sure I understand the symbol preemption scenario.
Wed, Aug 7
- Restore ET_CORE check
Agree with all these comments -- I'm no expert on when and when not to std::move, but this is undoing changes I've made to fix buildbots on different compilers.
I think it'd be good to also write a test that verifies the internal representation is always forward slashes on windows by running FileCheck directly on the thin archive instead of using llvm-ar t to look at it (e.g. see thin-archive.test). Or do we already have a test for that?
- Remove ET_CORE check
- null -> NUL
- Use more consistent error messages
- Check for no more lines in test output
- Other misc cleanup
Tue, Aug 6
(Also just want to say the print*RelocatableStackSizes methods look much better now, thanks for cleaning that up!)
Sorry, I had some draft comments yesterday but had to leave early, here are post-commit comments now:
Mon, Aug 5
Fri, Aug 2
- Rearrange NT_ constants in ELFDumper to match ordering in libObject header
- Sort enums by value and separate groups by whitespace
Thu, Aug 1
Left the question about whether --stack-sizes should be include in --all open. This is still a discussion point.
Wed, Jul 31
Tue, Jul 30
I'm not familiar with the .stack_sizes functionality in general, but it seems useful & could have saved me countless hours of debugging (large stack frames => stack overflows in recursive parsers) if I knew more about how it worked.
git clang-format does not understand moved files it turns out, so it formatted things that I didn't touch. I figure if this is going to happen it might as well be now, though. I can change this back though.
Mon, Jul 29
Committed this for you as r367241, including a rebase past r367238 (which I really hope I didn't mess up -- ninja check-lldb passed, at least).