Everything looks good for the tests that were broken before, thanks for waiting!

Sorry, I wanted to patch this in first and rerun tests to make sure the internal build step this broke doesn't have other issues -- I'll reply today

In D64797#1587681, @abrachet wrote:

I got it to work. The revert is here rL366219. I think it didn't work because I always clone with --depth 1? So I just created a fresh clone.

Temporarily reverted in r365712 due to the noted issue -- I don't think the fix should be too hard, but didn't seem trivial enough to just fix forward

This is an issue for fully linked executables that still have relocation sections, e.g. because it was linked with the --emit-relocs flag:

I'm seeing an error pulling this into our toolchain when trying to copy some files:

Thanks for the explanation. Temporarily reverted in r365000.

We're seeing several compilation timeouts as well. Temporarily reverted in r364846 since this review is ongoing.

(ditto that Ray should take another look, but looks mostly fine to me)

Switching these docs to rst seems (unfortunately) better, abandoning this attempt.

Sounds good, changed to use variable matching instead. This passes w/ either -fno-discard-value-names or -fdiscard-value-names used.

• Use filecheck variable matching instead of an explicit -fno-discard-value-names option

LGTM just with the naming nit from James (header_t&->const HeaderType&)

(just the one comment, then lgtm)

In D63394#1546401, @jhenderson wrote:

In D63394#1546292, @ychen wrote:

I'm totally fine with not commit this. But it seems just a small convenience from a tooling perspective (no need for the semantics of the symbol type) when you need the value but not in an OS or processor specific way and STT_LOOS looks better than "10"?

I may have been a bit hasty rejecting this. My concern is that I have already seen instances in LLVM where people possibly not well-versed in ELF try to use these as actual types in testing and in tools consuming these values, which can lead to confusion or worse, bogus output (e.g. llvm-readelf claiming that a symbol's type is STT_LOOS). @grimar, do you have any thoughts?

I replied to your llvm-dev thread. I think we should apply something like D63292, upgrade the buildbots, and then apply this change when reverting D63292.

Sure, committed as r363198

Looks like I'm on 1.7.5, from last year (http://www.sphinx-doc.org/en/master/changes.html#release-1-7-5-released-may-29-2018). Not sure how to check the bot version.

I intentionally added .html because I noticed the link on llvm.org is broken: http://llvm.org/docs/CommandGuide/llvm-addr2line.html links to http://llvm.org/docs/CommandGuide/llvm-symbolizer, which does not exist (http://llvm.org/docs/CommandGuide/llvm-symbolizer.html does).

Thanks for splitting up the patch! I should have requested that earlier.

• Clarify llvm-readelf compatibility

Can you upload this patch with context? Either use arc or upload w/ -U99999

In D63011#1534305, @jhenderson wrote:

In D63011#1534304, @rupprecht wrote:

I actually wonder if we should split out all the binary utilities to a separate section. We should try to advertise the replacement-ness of all the tools we have.

That's probably not a bad shout, though we'd have to figure out exactly what we mean by "binary utilities" as I suspect everybody has a slightly different interpretation of this. Maybe a section labelled "GNU replacements"

SGTM. There's a definitive list of that here: https://www.gnu.org/software/binutils/

In D63011#1534282, @jhenderson wrote:

Thanks @MaskRay.

In D63011#1534265, @MaskRay wrote:

Since llvm-objdump and llvm-nm are in the "Basic Commands" list, and llvm-readobj is used in various test directories: CodeGen/DebugInfo/MC/LTO/..., I think it qualifies as a Basic Command :)

I think the distinction is "tools in LLVM used by people" versus "tools used by LLVM developers (mostly for testing/debugging)".

Are you saying LLVM developers aren't people? :p