<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/Plugins/ObjectFile/COFF, branch users/nico/python-2</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] 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>[lldb/cmake] Implicitly pass arguments to llvm_add_library (#142583)</title>
<updated>2025-06-04T09:33:37+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2025-06-04T09:33:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2c4f67794bff4df984b43db453fc0f5241ee72c8'/>
<id>2c4f67794bff4df984b43db453fc0f5241ee72c8</id>
<content type='text'>
If we're not touching them, we don't need to do anything special to pass
them along -- with one important caveat: due to how cmake arguments
work, the implicitly passed arguments need to be specified before
arguments that we handle.

This isn't particularly nice, but the alternative is enumerating all
arguments that can be used by llvm_add_library and the macros it calls
(it also relies on implicit passing of some arguments to
llvm_process_sources).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If we're not touching them, we don't need to do anything special to pass
them along -- with one important caveat: due to how cmake arguments
work, the implicitly passed arguments need to be specified before
arguments that we handle.

This isn't particularly nice, but the alternative is enumerating all
arguments that can be used by llvm_add_library and the macros it calls
(it also relies on implicit passing of some arguments to
llvm_process_sources).</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Fix missing comsumeError() with LLDB_LOG in ObjectFileCOFF/PECOFF (#70793)</title>
<updated>2023-11-01T11:09:12+00:00</updated>
<author>
<name>Stefan Gränitz</name>
<email>weliveindetail@users.noreply.github.com</email>
</author>
<published>2023-11-01T11:09:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=43db8ac8ae56f24b5c06e9edb194fe1b7e9cbda0'/>
<id>43db8ac8ae56f24b5c06e9edb194fe1b7e9cbda0</id>
<content type='text'>
All `llvm::Error`s must be checked/consumed before destruction. Previously,
the errors in this patch were only consumed when logging was enabled.
Using `LLDB_LOG_ERROR` instead of `LLDB_LOG` fixes that, because it
calls `llvm::consumeError()` explicitly when logging is disabled.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
All `llvm::Error`s must be checked/consumed before destruction. Previously,
the errors in this patch were only consumed when logging was enabled.
Using `LLDB_LOG_ERROR` instead of `LLDB_LOG` fixes that, because it
calls `llvm::consumeError()` explicitly when logging is disabled.</pre>
</div>
</content>
</entry>
<entry>
<title>ObjectFile: introduce a COFF object file plugin</title>
<updated>2023-05-07T19:40:44+00:00</updated>
<author>
<name>Saleem Abdulrasool</name>
<email>compnerd@compnerd.org</email>
</author>
<published>2023-05-07T18:12:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5014830ede78e55e2c638948ca00cea045eac9ce'/>
<id>5014830ede78e55e2c638948ca00cea045eac9ce</id>
<content type='text'>
Windows uses COFF as an object file format and PE/COFF as an executable
file format. They are subtly different and certain elements of a COFF
file may not be present in an executable. Introduce a new plugin to add
support for the COFF object file format which is required to support
loading of modules built with -gmodules. This is motivated by Swift
which serialises debugging information into a PCM which is a COFF object
file.

Differential Revision: https://reviews.llvm.org/D149987
Reviewed By: bulbazord
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Windows uses COFF as an object file format and PE/COFF as an executable
file format. They are subtly different and certain elements of a COFF
file may not be present in an executable. Introduce a new plugin to add
support for the COFF object file format which is required to support
loading of modules built with -gmodules. This is motivated by Swift
which serialises debugging information into a PCM which is a COFF object
file.

Differential Revision: https://reviews.llvm.org/D149987
Reviewed By: bulbazord
</pre>
</div>
</content>
</entry>
</feed>
