rebase

In D128094#3593734, @aheejin wrote:

(Also we can't just always require the presence of e.g. the
function or global sections, because a binary may just have any functions.
There's only an problem if the name or linking section tries to name a
nonexistent function).

Code LGTM, but not sure what this sentence means.. Can you provide a little more context?

• expand comment

• review comments

In D126509#3559905, @jhenderson wrote:

I'm happy for @sbc100 to review wasm-only changes like this patch, without contributing myself. If the change starts impacting generic llvm-objcopy code, I'd like to review it though.

• use start.s as a test instead

@jhenderson or others, would you like to review this too, or is sbc's review sufficient?

• remove stray blank line

OK, the prerequisite refactoring has landed, and this patch is now based on main, please take a look.

• Merge branch 'main' into objcopy-known

include all the diffs

also update reloc and symbol type functions

In D126509#3541775, @jhenderson wrote:

Looks like there's no test case?

• Merge branch 'sectionTypeToString' into objcopy-known

Deduplicate

LGTM but will this require a change to clang and/or EMCC first?

Yeah, letting the user override with the manual mechanisms seems like a good thing, probably?

what happens when you use attribute(export-name) in clang, along with -fvisibility=hidden? (or is there some other way force an export?)

This looks good. Keep the interleaving if you find it more readable.
But thanks for the pointer @asb, I knew about the LLVM IR version of that tool but didn't know there was a MIR one.

This looks great! I guess the test for this will be when the fix for the MIR verifier lands, and it will start throwing errors if this somehow breaks, right?

In D123763#3485836, @sbc100 wrote:

This new test has been failing on the emscripten builders.. seemingly ever since it landed:

Ah, right I forgot we already combined the default segments. That's probably fine as a default behavior.

Would there still be an advantage to combining the segments? e.g. would the library load faster if there were only one?

This code is fine as a reflection of the current state of the proposal though.

I assume these llvm_unreachables your're adding in this CL are the places that will be filled in in subsequent CLs?

can-haz test?

Looks OK to me. All of these options handle explicit overrides to the ABI which I guess just didn't work before but doesn't change any defaults. We should probably put something in the emscripten release notes with a list of the flags that now actually do something, just in case someone was accidentally using them before :)

I haven't reviewed this yet, but since we got one of these before and never merged it (https://reviews.llvm.org/D101464) we should probably land one of these.

I guess the existing tls.s test case still covers the case where neither the symbol nor the segment is marked as TLS but the name is .tdata?

The code, test and the behavior LGTM though.

Mostly I was confused by the fact that it says Wasm EH "used with" either Emscripten EH (which doesn't make sense) or Wasm EH (redundant). But I guess you mean the wasm EH primitive, used to implement C++ EH and setjmp/longjmp?

Wasm EH, used with either of Emscripten EH or Wasm EH, does not allow
Do you mean "Wasm SjLj?"

fix diff

just one blank line

Also +cc @pfaffe and @azakai