Mostly looks okay. I think there is no testing for the assembly parser being able to parse the new section type?

LGTM! Nice work! (Also cc'ed both @ikudrin and @dblaikie who regularly work in the DWARF area).

Looks good from my point of view. Might be worth a second opinion (@grimar/@MaskRay/@rupprecht/@alexshap?)

LGTM, thanks for working on this.

LGTM.

Rename test inputs and add comment.

Generally looks fine, barring nits. I wonder whether it might be easier for downstream providers such as my team to merge this patch in if it were in separate commits for each of the major changes, but I don't really mind.

Looks good, aside from one question.

LGTM, with nit.

A couple of remaining comment suggestions, otherwise I think this looks good.

In D87935#2285841, @dblaikie wrote:

In D87935#2284630, @jhenderson wrote:

If I had to pick between the two existing options, I think I have a marginal preference for this one, since it requires less code and is less surprising to someone who might not be too familiar with the code - I would expect a list of units to be in offset order naturally, and not expect to have to go through some sort of sorting procedure in the future.

Fair - appreciate the perspective. One other wrinkle here is that if we support the "type_units()" API (I don't think anyone's actually using it, so I'd probably delete it for now) it'll need to use a fancy iterator solution too - concat_iterator + filter_iterator to take the v5 type units out of the debug_info units, and concat that with the v4 type units from debug_types.

I'm happy for that little extra complexity. I think it intuitively makes sense, even if it does mean messing about a little in the code.

Looks good.

LGTM, assuming I'm not mistaken in thinking there's another patch related to this one.

In D87667#2285036, @tinti wrote:

• Drop the "_style" in the name of the function.
• Add ":" test.
• Add comment about LLVM is_absolute.
• Add Vector constructor.

Now I think it is better to call it "is_gnu_absolute". The "style" is already used for style::{posix,windows,native}.
After reading the comments it was confusing. It might sound like we were introducing a new style::gnu which is not the case.

I can revert back if you don't agree. Please let me know.

Do we actually have any non-fatal errors in llvm-objcopy etc currently? If not, I think a better approach would be to simply bubble up the errors via Expected and Error usage, and handle the failures in the client code directly. The client code could then choose to either report them as errors (or warnings) and/or abort what it was doing. I imagine in the case of dwarfutil, you'd be best off aborting optimizing a given CU's debug data if it looked dodgy somehow, in which case, you don't need to distinguish between different classes of errors. This is the approach we take in our downstream port for our debug line rewriting that we've implemented.

In D87899#2284145, @MaskRay wrote:

All the passing of FirstSym is for &Sym - &FirstSym in ELF.h getExtendedSymbolTableIndex. If we only care about the index, passing around the index rather than the first symbol probably makes more sense?

In D87758#2281272, @grimar wrote:

Should the option name be more specific? --error-handling-script sounds like all errors can be handled with a script,
though this is only intended to be used for missing libraries errors, right?

It can be --missing-lib-err-handler, --missing-lib-ext-script, or something better probably.

LGTM, thanks!

My instinct is that I prefer a third approach - simply keep both combined and separate lists - the combined list (could be a vector or an ordered map) is the offset-ordered list of all units, whilst there are then separate lists for compile and type units, with members being pointers to the units stored in the primary list. I think this has the advantage of being very explicit about things, with the drawback being that there are multiple members to keep in sync (possibly alleviated by having a wrapper class around the containers).

Thanks for the reviews. I'll land this later today.

Remove hidden.

LGTM!

Maybe worth stating in the description and/or title that you are using CHECK-NEXT explicitly to achieve this. Otherwise, LGTM.

This sounds like a useful thing too. It should be fairly straightforward to test, as it's possible to e.g. have a python script in the test, which gets executed. Could you add test cases, please?

I guess if you wanted to add explicit testing that the behaviour happens regardless of the presence of specific load commands, that would be possible, using a minimal Mach-O file, but I don't mind if you don't want to. LGTM, if you don't.

I might be missing it, but do you have direct testing showing that the default for IncludeDirs\Files\Opcodes is an empty output, when the output is written? I think it's important that this is tested.

I've done a partial review to keep you going. I'm out of time to look at this further today though, especially given how cold I am on the patch. Many of my comments apply to multiple tests, even if I haven't got to those tests.

In D87824#2279183, @grimar wrote:

LGTM. Worth waiting for @MaskRay or someone else opinion too.

LGTM.

Address @grimar's comments (added additional comments, used split-file, renamed various things). Also renamed two tests using split-file which are not specifically .ll or .s.

LGTM.

In D87732#2278196, @phosek wrote:

In D87732#2275943, @jhenderson wrote:

I'm not convinced this is really correct. After all, a path with mixed separators (e.g. '/my/path\to\foo') could be a Windows path rooted at the current drive. This mixed style can sometimes happen when things get concatenated together, so I don't think it's compeletely unreasonable.

I'm also concerned that if we guess wrong, the behaviour will end up breaking. For example, if the path were a Windows path "/my/path\../to/foo", I'd expect a remove_dots call (without worrying about slash normalisation) to result in "/my/to/foo", but if the code is using Posix style, will it actually result in the path being left unchanged?

I can think of two competing alternatives:

1. add an option to remove_dots to not do the separator canonicalization. I'm not sure whether this can be done unambiguously however - which separator should be removed when a directory is removed due to dots? The one before the removed parts? After them?
2. change all '\' to '/' unconditionally. However, this might break Linux paths with '\' in.

None of these solutions is perfect and I'm not even sure if there's one. Even if we improve remove_dots, there's still the existing issue with sys::path::append: which separator should we use when combining compilation dir, include dir and the file name.

Maybe we should instead update Clang to do the normalization when generating debug info and always use /, and then always use / unconditionally when combining paths on the consumer side (but don't do any normalization)?

I've made two inline suggestions, but I'm not at all familiar with the other code, so can't further assist there.

I've addressed the main issues I aimed to resolve in other patches. There may be some issues with odd output of error messages when the output is interleaved, but I have other priorities to work on at this point. If someone wants to work on this furhter, it's probably best done in a new review.

In D87667#2275659, @tinti wrote:

In D87667#2273502, @jhenderson wrote:

On Windows, paths starting with drive letter pattern are absolute.

This isn't a difference is it? That's also the behaviour for is_absolute, I believe?

I forgot this comment.

is_absolute is really hard to read. But I think you are right.

I think it considers c:\ as absolute but does not c: [1].

[1] https://github.com/llvm/llvm-project/blob/master/llvm/lib/Support/Path.cpp#L69

Thanks, LGTM.

I'm not convinced this is really correct. After all, a path with mixed separators (e.g. '/my/path\to\foo') could be a Windows path rooted at the current drive. This mixed style can sometimes happen when things get concatenated together, so I don't think it's compeletely unreasonable.

LGTM, thanks!

LGTM!

Please add the new option to the Command Guide documentation.

We should probably have a bit more direct testing for this behaviour, as I agree it's useful and we don't want to accidentally lose the behaviour in a future change. Maybe a unit test, I don't really mind.

On Windows, paths starting with drive letter pattern are absolute.

This isn't a difference is it? That's also the behaviour for is_absolute, I believe?

There seems to be more going on in this patch than the description talks about. In particular, it looks like this patch causes relocations to be printed when they weren't before. I don't think this is necessarily a problem, but it needs explaining in the description at least, and if sensibly practical, should actually be a separate patch, to minimise behaviour changes per patch.

LGTM, with nit.

LGTM!

LGTM.

LGTM!

LGTM too, thanks!

In D87453#2270832, @grimar wrote:

Is it OK or too much?

I think there's probably some value testing every value, as there is a chance that a future refactor could lead to a bug where there is ambiguity between a CORE note value and another variety of note, for example. Having a test for each individual value ensures that any such bug would be picked up. However, I'm not dead set on this idea, and can see counter-arguments to it. LGTM, but happy to defer to others opinion on whether testing each value is atually necessary.

This looks a lot cleaner. LGTM.

LGTM, with a couple of nits.

Looks good from my point of view, but best wait for the conversation with @dblaikie to be resolved.

LGTM.

In D80713#2261550, @rochauha wrote:

3 of the test cases - kd-sgpr.s, kd-vgpr.s, kd-zeroed-gfx10.s fail with the PowerPC buildbot (http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/53608). From what I understand, these tests should only run if AMDGPU target is built. The lit.local.cfg file specifies that.

It seems in general that a build system will want a different symbol ordering file per output, so any involving more than one output would need them specified individually. I don't think a global variable that sets it for all links involved in a build (including CMake links) really makes sense as a result. Limiting it down to a single file via any mechanism (whether within the file or command-line option) sounds like a sticking plaster solution rather than actually the right fix. As @MaskRay has already mentioned, the fix is to specify the right options for the right link. I would think the same applies for options like --dynamic-list, since you might want to export different symbols for different links. Usually the way to do this is with a lower-level customisation of linker options.

In D78938#2261411, @jfb wrote:

On C++20 mode rotting: it won't if someone sets up a bot. If it rots, then it's easier to un-rot with Barry's patch.

No more comments from me, but please give @kzhuravl a chance to respond before pushing this patch.

You should add a [test] tag to the patch/commit title. LGTM, with that and the inline nit.

LGTM.

LGTM with comment update.

@kzhuravl, do you have any additional comments to add at all, since you rejected the original patch?

LGTM.

LGTM too. I noticed that --version (and -V) are missing from the Command Guide for llvm-install-name-tool, along with --help, unlike e.g. llvm-objcopy. Perhaps worth a separate patch if you get a few minutes to fix the doc.