<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp, branch users/mingmingl-llvm/samplefdo-profile-format</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[lldb] Corretly parse Wasm segments (#154727)</title>
<updated>2025-08-26T21:56:25+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-08-26T21:56:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=aadc708e78568f1ec5713dd4ba768e77044b651d'/>
<id>aadc708e78568f1ec5713dd4ba768e77044b651d</id>
<content type='text'>
My original implementation for parsing Wasm segments was wrong in two
related ways. I had a bug in calculating the file vm address and I
didn't fully understand the difference between active and passive
segments and how that impacted their file vm address.

With this PR, we now support parsing init expressions for active
segments, rather than just skipping over them. This is necessary to
determine where they get loaded.

Similar to llvm-objdump, we currently only support simple opcodes (i.e.
constants). We also currently do not support active segments that use a
non-zero memory index. However this covers all segments for a
non-trivial Swift binary compiled to Wasm.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
My original implementation for parsing Wasm segments was wrong in two
related ways. I had a bug in calculating the file vm address and I
didn't fully understand the difference between active and passive
segments and how that impacted their file vm address.

With this PR, we now support parsing init expressions for active
segments, rather than just skipping over them. This is necessary to
determine where they get loaded.

Similar to llvm-objdump, we currently only support simple opcodes (i.e.
constants). We also currently do not support active segments that use a
non-zero memory index. However this covers all segments for a
non-trivial Swift binary compiled to Wasm.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Improve error handling in ObjectFileWasm (#154433)</title>
<updated>2025-08-19T23:00:31+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-08-19T23:00:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7cd61793edbb4e6dbc0fb92e5d6d85cabfa62b40'/>
<id>7cd61793edbb4e6dbc0fb92e5d6d85cabfa62b40</id>
<content type='text'>
Improve error handling in ObjectFileWasm by using helpers that wrap
their result in an llvm::Expected. The helper to read a Wasm string now
return an Expected&lt;std::string&gt; and I created a helper to parse 32-bit
ULEBs that returns an Expected&lt;uint32_t&gt;.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Improve error handling in ObjectFileWasm by using helpers that wrap
their result in an llvm::Expected. The helper to read a Wasm string now
return an Expected&lt;std::string&gt; and I created a helper to parse 32-bit
ULEBs that returns an Expected&lt;uint32_t&gt;.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Create sections for Wasm segments (#153634)</title>
<updated>2025-08-19T18:07:49+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-08-19T18:07:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=8bd9897815a5a07b028e7eb8be86c1f8e423395a'/>
<id>8bd9897815a5a07b028e7eb8be86c1f8e423395a</id>
<content type='text'>
This is a continuation of #153494. In a WebAssembly file, the "name"
section contains names for the segments in the data section
(WASM_NAMES_DATA_SEGMENT). We already parse these as symbols, and with
this PR, we now also create sub-sections for each of the segments.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a continuation of #153494. In a WebAssembly file, the "name"
section contains names for the segments in the data section
(WASM_NAMES_DATA_SEGMENT). We already parse these as symbols, and with
this PR, we now also create sub-sections for each of the segments.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Support parsing data symbols from the Wasm name section (#153494)</title>
<updated>2025-08-14T15:01:41+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-08-14T15:01:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d0e40ff705cd746f118a118bd882af422bc026f8'/>
<id>d0e40ff705cd746f118a118bd882af422bc026f8</id>
<content type='text'>
This PR adds support for parsing the data symbols from the WebAssembly
name section, which consists of a name and address range for the
segments in the Wasm data section. Unlike other object file formats,
Wasm has no symbols for referencing items within those segments (i.e.
symbols the user has defined).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This PR adds support for parsing the data symbols from the WebAssembly
name section, which consists of a name and address range for the
segments in the Wasm data section. Unlike other object file formats,
Wasm has no symbols for referencing items within those segments (i.e.
symbols the user has defined).</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Use numeric_limits for all overflow checks in ObjectFileWasm (#153332)</title>
<updated>2025-08-13T01:49:03+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-08-13T01:49:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=84c5b9525e09accd8859005f6eb651fc14808f74'/>
<id>84c5b9525e09accd8859005f6eb651fc14808f74</id>
<content type='text'>
Use std::numeric_limits&lt;uint32_t&gt;::max() for all overflow checks in
ObjectFileWasm and fix a few locations where I incorrectly used `&gt;=`
instead of `&gt;`.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use std::numeric_limits&lt;uint32_t&gt;::max() for all overflow checks in
ObjectFileWasm and fix a few locations where I incorrectly used `&gt;=`
instead of `&gt;`.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Support parsing the Wasm symbol table (#153093)</title>
<updated>2025-08-12T20:12:30+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-08-12T20:12:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5be2063e1083773d4863d94d357f0e890c646fde'/>
<id>5be2063e1083773d4863d94d357f0e890c646fde</id>
<content type='text'>
This PR adds support for parsing the WebAssembly symbol table. The
symbol table is encoded in the "names" section and contains names and
indexes into other sections. For now we only support parsing function
(code) symbols. The result is that you can set breakpoints by symbol
name, while previously breakpoints by name required debug info (DWARF).

This is also necessary for Swift, which checks for the presence of
`swift_release` as a heuristic to determine if there's a static Swift
stdlib.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This PR adds support for parsing the WebAssembly symbol table. The
symbol table is encoded in the "names" section and contains names and
indexes into other sections. For now we only support parsing function
(code) symbols. The result is that you can set breakpoints by symbol
name, while previously breakpoints by name required debug info (DWARF).

This is also necessary for Swift, which checks for the presence of
`swift_release` as a heuristic to determine if there's a static Swift
stdlib.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Support DW_OP_WASM_location in DWARFExpression (#151010)</title>
<updated>2025-07-30T16:20:37+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2025-07-30T16:20:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c2548a8c4c581bfd7c2b7738508fff4d85413cd6'/>
<id>c2548a8c4c581bfd7c2b7738508fff4d85413cd6</id>
<content type='text'>
Add support for DW_OP_WASM_location in DWARFExpression. This PR rebases
#78977 and cleans up the unit test. The DWARF extensions are documented
at https://yurydelendik.github.io/webassembly-dwarf/ and supported by
LLVM-based toolchains such as Clang, Swift, Emscripten, and Rust.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for DW_OP_WASM_location in DWARFExpression. This PR rebases
#78977 and cleans up the unit test. The DWARF extensions are documented
at https://yurydelendik.github.io/webassembly-dwarf/ and supported by
LLVM-based toolchains such as Clang, Swift, Emscripten, and Rust.</pre>
</div>
</content>
</entry>
<entry>
<title>[LLDB] Unify DWARF section name matching (#141344)</title>
<updated>2025-06-09T08:46:50+00:00</updated>
<author>
<name>nerix</name>
<email>nerixdev@outlook.de</email>
</author>
<published>2025-06-09T08:46:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c6670fa20d434a85e167e88aa6a4f56bfc02af2f'/>
<id>c6670fa20d434a85e167e88aa6a4f56bfc02af2f</id>
<content type='text'>
Different object file formats support DWARF sections (COFF, ELF, MachO,
PE/COFF, WASM). COFF and PE/COFF only matched a subset. This caused some
GCC executables produced on MinGW to have issue later on when debugging.
One example is that `.debug_rnglists` was not matched, which caused
range-extraction to fail when printing a backtrace.

This unifies the parsing of section names in
`ObjectFile::GetDWARFSectionTypeFromName`, so all file formats can use
the same naming convention. Since the prefixes are different,
`GetDWARFSectionTypeFromName` only matches the suffixes (i.e. `.debug_`
needs to be stripped before).

I added two tests to ensure the sections are correctly identified on
Windows executables.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Different object file formats support DWARF sections (COFF, ELF, MachO,
PE/COFF, WASM). COFF and PE/COFF only matched a subset. This caused some
GCC executables produced on MinGW to have issue later on when debugging.
One example is that `.debug_rnglists` was not matched, which caused
range-extraction to fail when printing a backtrace.

This unifies the parsing of section names in
`ObjectFile::GetDWARFSectionTypeFromName`, so all file formats can use
the same naming convention. Since the prefixes are different,
`GetDWARFSectionTypeFromName` only matches the suffixes (i.e. `.debug_`
needs to be stripped before).

I added two tests to ensure the sections are correctly identified on
Windows executables.</pre>
</div>
</content>
</entry>
<entry>
<title>Move from llvm::makeArrayRef to ArrayRef deduction guides - last part</title>
<updated>2023-01-10T10:47:43+00:00</updated>
<author>
<name>serge-sans-paille</name>
<email>sguelton@mozilla.com</email>
</author>
<published>2023-01-09T17:11:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=984b800a036fc61ccb129a8da7592af9cadc94dd'/>
<id>984b800a036fc61ccb129a8da7592af9cadc94dd</id>
<content type='text'>
This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

Differential Revision: https://reviews.llvm.org/D141298
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

Differential Revision: https://reviews.llvm.org/D141298
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Use std::optional instead of llvm::Optional (NFC)</title>
<updated>2023-01-07T22:18:35+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2023-01-07T22:18:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2fe8327406050d2585d2ced910a678e28caefcf5'/>
<id>2fe8327406050d2585d2ced910a678e28caefcf5</id>
<content type='text'>
This patch replaces (llvm::|)Optional&lt; with std::optional&lt;.  I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/ADT/Optional.h", etc.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch replaces (llvm::|)Optional&lt; with std::optional&lt;.  I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/ADT/Optional.h", etc.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
</pre>
</div>
</content>
</entry>
</feed>
