Stream: git-wasmtime

Topic: wasmtime / PR #4314 Change how unwind information is stor...

Wasmtime GitHub notifications bot (Jun 24 2022 at 14:17):

alexcrichton opened PR #4314 from xdata-pdata to main:

Unwind information on Windows is stored in two separate locations. The
first location is the unwind information itself which corresponds to
UNWIND_INFO. The second location is a list of RUNTIME_INFO
structures which point to function bodes and UNWIND_INFO structures.

Currently in Wasmtime the UNWIND_INFO structures are stored just after
functions themselves with a somewhat cryptic comment indicating that
Windows prefers this (I'm unsure as to the provenance of this comment).
The RUNTIME_INFO data is then stored in a separate section which has
the custom name of _wasmtime_winx64_unwind.

After my recent foray into trying to debug windows-2022 bad unwind
information again I realized though that Windows actually has official
sections for these two unwind information items. The .xdata section is
used to store the UNWIND_INFO structures and the .pdata section
stores the RUNTIME_INFO list. To try to be somewhat idiomatic and
perhaps one day even hook into standard Windows debugging tools I went
ahead and refactored how our unwind information is stored to match this.

Perhaps the main benefit of this is that it reduces the size of the
read/execute section of the binary. Previously the unwind information
was executable since it was stored in the .text section, but
unnecessarily so. Now it's in a read-only section which is in theory a
small amount of hardening.

Otherwise though I don't think this will really help all that much to
hook up in to standard debugging tools like objdump because it's all
still stored in an ELF file rather than a COFF file.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Jun 24 2022 at 14:17):

alexcrichton requested peterhuene for a review on PR #4314.

Wasmtime GitHub notifications bot (Jun 28 2022 at 02:46):

peterhuene created PR review comment:

It's fairer to say that every address in the RUNTIME_FUNCTION structure must be start-of-text-section relative (thus necessitating that .xdata comes _after_ the text section) because we're using RtlAddFunctionTable to register the .pdata section contents and using the loaded text section's address as the "image base address".

I think mentioning "relocations" here might be confusing since technically no fixups are being recorded in the artifact to apply at load time (unlike what a real .pdata section would have in a PE since RtlAddFunctionTable wouldn't be used in that case).

Wasmtime GitHub notifications bot (Jun 28 2022 at 02:46):

peterhuene submitted PR review.

Wasmtime GitHub notifications bot (Jun 28 2022 at 02:46):

peterhuene created PR review comment:

Nit: append_data argument was removed but still documented above.

Wasmtime GitHub notifications bot (Jun 28 2022 at 02:46):

peterhuene submitted PR review.

Wasmtime GitHub notifications bot (Jun 28 2022 at 02:53):

peterhuene edited PR review comment.

Wasmtime GitHub notifications bot (Jun 28 2022 at 14:41):

alexcrichton updated PR #4314 from xdata-pdata to main.

Wasmtime GitHub notifications bot (Jun 28 2022 at 14:41):

alexcrichton has enabled auto merge for PR #4314.

Wasmtime GitHub notifications bot (Jun 28 2022 at 15:40):

alexcrichton merged PR #4314.

Last updated: Nov 22 2024 at 16:03 UTC