Add initial support for DWARF Fission

[yowl]

Wasmtime supports debugging with DWARF, and this PR adds initial support for DWARF fission. DWARF fission has advantages in linking and wasm size (https://developer.chrome.com/blog/faster-wasm-debugging) as it separates the debug_info section into a separate file leaving a DW_TAG_skeleton_unit in the main wasm file.

This PR only supports DWARF pacakges, .dwp files. It should also be possible to support.dwo files, but I've not done that here.

[github-actions]

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasi", "wasmtime:api", "wasmtime:c-api"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api, wasmtime:c-api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[alexcrichton]

Thanks for this! I've got some high level comments about the rough structure here, mostly to help centralize things bit more in the "dwarf processing area" and additionally API guidance for enabling usage of this in all case but not necessarily requiring it to be front-and-center in the embedding API.

[yowl]

I think I've addressed the first set of feedback and I think it looks cleaner. There are some safe-to-deploy and some feature looking errors to deal with still

[alexcrichton]

Looking good! I wanted to offer, though, if you'd like I'm happy to help out with the refactoring required to make ModuleBuilder come into existence. That's a big chunk of this change and isn't related directly to DWARF fission, so I can help out land the refactorings required to get ModuleBuilder itself in place and that would help slim down this change to just DWARF fission.

I say this because I've got a number of comments about specific details about the API, but I don't want to bog you down too much if you're mainly interested in the DWARF bits.

[yowl]

I wanted to offer, though, if you'd like I'm happy to help out with the refactoring required to make ModuleBuilder come into existence.

That would be very kind, thanks! You are right my primary goal is DWARF fission, so I can land dotnet/runtimelab#2264 which I can't really do properly without wasmtime support.

[alexcrichton]

@yowl this failure looks legitimate in the sense of probably-caused-by-this PR. Do you know if that perhaps means the LLDB we're using in CI is missing something and/or is too old?

[yowl]

This looks relevant llvm/llvm-project#55575 Seems like we have to add some missing python stuff.

[yowl]

Although its odd the other tests are passing. What version of Ubuntu is it? Can we run lldb -P to see what paths are expected to be present?

[alexcrichton]

I'm not sure myself, we don't have anything special beyond the standard github actions runners. If you'd like you can push up a commit with "prtest:full" in the commit message and it'll run the full test suite here on the PR to help debug.

[yowl]

@alexcrichton , change a couple of things

Added workaround for https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1972855
Forced use of latest lldb available, 15
Added logic to CodeBuilder to load dwp when a wasm path is supplied.
Fixed inconsistency in source file names