I think I can accept it (with nits fixed), so LGTM. I've added few last minor comments/notes.
(there also seems to be some issues with English grammar in comments, but it is not a place where I can help much).

Looks mostly good to me. I'd suggest to focus on refining the comments in test cases.
Currenty it is often not clear what is tested and what is expected result.
E.g:

Few more comments. I think that error reporting could be better, we should probably use
the power of Expected<> and show the real errors, rather than hiding them under standard messages for error codes.

I apologize for my belated feedback. I am still on vacation, but I'd like to add my 5 cents about this particular patch to try to push it forward.

• Addressed review comment.

• Fix the obj2yaml crash on a binary processed by llvm-strip --remove-sections. The issue happened when there was no section header table. I've fixed it and added a test case to program-headers.yaml. Note that currently obj2yaml doesn't emit a SectionHeaderTable chunk with NoHeaders = true for such a case. But this issue is unrelated to this patch, we already have the following FIXME in the eshnum.yaml test:

In D95158#2530153, @jhenderson wrote:

In D95158#2530091, @grimar wrote:

In D95158#2529509, @rahmanl wrote:

I am surprised this patch hasn't been automatically updated to show the committed status after I pushed it (https://github.com/llvm/llvm-project/commit/3ca502a7d60787abe14db1fa541950ff79c7585b). Maybe I should've used arc land instead of git push?

Probably because you've used "Differential Revision". The latter word should be "revision"

No, it definitely should be Revision (upper-case).

In D95609#2530142, @jhenderson wrote:

LGTM. I've also approved D95246. That's a larger change, so perhaps let that land first, if you can then rebase and commit. If it hasn't landed before you need to be stopping work, feel free to land this first though, given you're away soon.

In D95158#2529509, @rahmanl wrote:

I am surprised this patch hasn't been automatically updated to show the committed status after I pushed it (https://github.com/llvm/llvm-project/commit/3ca502a7d60787abe14db1fa541950ff79c7585b). Maybe I should've used arc land instead of git push?

• Addressed review comments.

In D95591#2529833, @MaskRay wrote:

Program headers are not subsidiary of the section header table. ProgramHeaderType is fine, but it probably should not have Segments:. The program headers can still be described the current ProgramHeaders:.

• Addressed review comments.

• Addressed review comments.
• Improved testing.

In D95591#2527530, @jhenderson wrote:

I might well have missed it, but I don't recall seeing any dedicated obj2yaml tests?

In D95341#2524716, @jhenderson wrote:

LGTM.

In D95341#2524529, @grimar wrote:

Hi guys.
I am sorry for pinging this too early, but I am planning a ~6 weeks vacation starting from 1st of february
and I wonder if there is something I can do for this to land it or if there are any concerns about this change?

No problem. Somehow this slipped off my review pile, so I hadn't seen it. Let me know if there are any other reviews I haven't done by the end of the day.

Hi guys.
I am sorry for pinging this too early, but I am planning a ~6 weeks vacation starting from 1st of february
and I wonder if there is something I can do for this to land it or if there are any concerns about this change?

In D95354#2522343, @jhenderson wrote:

In D95354#2522323, @grimar wrote:

It turns out this wasn't NFC, one of LLDB test cases started to crash.
I've fixed it in rG2a33b092f5b175a21680b3980ff2019bc1c65b12.

The difference was that before this patch we set the sh_link for symbol tables basing on their names (E.g ".symtab"),
now we set this field basing on section types (e.g SHT_SYMTAB).
The mentioned test case has a .text section of type SHT_SYMTAB and it did not expect to see a sh_link field set it seeems.

Based on my casual reading of that test, I wonder if you found a bug in the tool there - it looks like the intent is for section types to trump section names, which surely should mean the use of sh_link would be correctin this case? Perhaps we should highlight this to the LLDB developers (pinging @JDevlieghere for example).

E.g. it seems that the expected behavior of llvm-objcopy would be to drop the sh_link for symbol table in this case. Because it is of SHT_NOBITS type.
Perhaps I'd wait from some input from @MaskRay as he was the author of the test case I think.

In D95364#2522324, @jhenderson wrote:

Looks reasonable, but perhaps fixing the llvm-objcopy issue first would be best. What do you think?

It turns out this wasn't NFC, one of LLDB test cases started to crash.
I've fixed it in rG2a33b092f5b175a21680b3980ff2019bc1c65b12.

I like this approach.

• Addressed review comment.

As far I understand, looking on the description of D94239, the message on z/OS looks like "EDC5129I No such file or directory.".
I guess the EDC5129I is a stable error code? So why not to check for a possible EDC5129I prefix word instead of .*?
(The same applies for other possible errors)

A minor nit from me, the rest looks fine.

This looks to me it solves a specific corner case, but I really don't feel I have enough knowledges about embedded world/scripts to say whether it is a good or bad thing to support it.
It seems matches to what GNU ld/gold do. I'll add Peter who I guess might have an opinion about this.

• Addressed review comments.

D95140 was posted instead.

• Addressed review comments.

In D95140#2514914, @jhenderson wrote:

It feels like there needs to be testing there for writing the section header table in the right place in the YAML (with Offset if needed), but I don't see that yet.

LGTM with a nit, please wait for others.

In D95124#2512145, @jhenderson wrote:

missing check-prefix. Not sure how I didn't spot the latter...

This LGTM, but please wait for others.

@MaskRay, are you OK with it?

Ping.

• Added test cases.

• Addressed review comment.

• Addressed review comments.

• Format.

• Addressed review comments.