<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/Support/Windows, 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>[DLCov] Origin-Tracking: Enable collecting and symbolizing stack traces (#143591)</title>
<updated>2025-07-02T11:01:17+00:00</updated>
<author>
<name>Stephen Tozer</name>
<email>stephen.tozer@sony.com</email>
</author>
<published>2025-07-02T11:01:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=35626e97d886dcb5f335af8abcfadb5f6bbcc64a'/>
<id>35626e97d886dcb5f335af8abcfadb5f6bbcc64a</id>
<content type='text'>
This patch is part of a series that adds origin-tracking to the debugify
source location coverage checks, allowing us to report symbolized stack
traces of the point where missing source locations appear.

This patch adds a pair of new functions in `signals.h` that can be used
to collect and symbolize stack traces respectively. This has major
implementation overlap with the existing stack trace
collection/symbolizing methods, but the existing functions are
specialized for dumping a stack trace to stderr when LLVM crashes, while
these new functions are meant to be called repeatedly during the
execution of the program, and therefore we need a separate set of
functions.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch is part of a series that adds origin-tracking to the debugify
source location coverage checks, allowing us to report symbolized stack
traces of the point where missing source locations appear.

This patch adds a pair of new functions in `signals.h` that can be used
to collect and symbolize stack traces respectively. This has major
implementation overlap with the existing stack trace
collection/symbolizing methods, but the existing functions are
specialized for dumping a stack trace to stderr when LLVM crashes, while
these new functions are meant to be called repeatedly during the
execution of the program, and therefore we need a separate set of
functions.</pre>
</div>
</content>
</entry>
<entry>
<title>[Support] Remove workarounds for building with mingw.org toolchains (#145683)</title>
<updated>2025-06-26T10:23:42+00:00</updated>
<author>
<name>Martin Storsjö</name>
<email>martin@martin.st</email>
</author>
<published>2025-06-26T10:23:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=163871c2d269fe0bf34800739245aa55fe851be0'/>
<id>163871c2d269fe0bf34800739245aa55fe851be0</id>
<content type='text'>
Assume that mingw builds are made with mingw-w64 headers.

The old mingw.org distribution isn't even accessible at the moment, and
their project hosting site (osdn.net) seems to have been down for a
couple of years, and their old project hosting (at sourceforge.net)
hasn't been updated since 2018.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Assume that mingw builds are made with mingw-w64 headers.

The old mingw.org distribution isn't even accessible at the moment, and
their project hosting site (osdn.net) seems to have been down for a
couple of years, and their old project hosting (at sourceforge.net)
hasn't been updated since 2018.</pre>
</div>
</content>
</entry>
<entry>
<title>[Support] Remove an outdated MinGW workaround (#145294)</title>
<updated>2025-06-24T14:13:44+00:00</updated>
<author>
<name>Martin Storsjö</name>
<email>martin@martin.st</email>
</author>
<published>2025-06-24T14:13:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7a4b3925598c07f5b4523a701ba6c34e483078d6'/>
<id>7a4b3925598c07f5b4523a701ba6c34e483078d6</id>
<content type='text'>
mingw-w64 has had the _HEAPOK define since the initial commits in 2007;
unclear when/where it was added for mingw.org headers, but it does seem
to exist there as well (at least in versions from 2011).

This workaround stems from 53fbecce6e8b7d1f024e3dc6df4160fe9a577ff1 from
2004 - it is no longer relevant today.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
mingw-w64 has had the _HEAPOK define since the initial commits in 2007;
unclear when/where it was added for mingw.org headers, but it does seem
to exist there as well (at least in versions from 2011).

This workaround stems from 53fbecce6e8b7d1f024e3dc6df4160fe9a577ff1 from
2004 - it is no longer relevant today.</pre>
</div>
</content>
</entry>
<entry>
<title>[Support][Cygwin] Fix handling of Process symbol lookup. (#143072)</title>
<updated>2025-06-09T19:19:37+00:00</updated>
<author>
<name>jeremyd2019</name>
<email>github@jdrake.com</email>
</author>
<published>2025-06-09T19:19:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d659364295f6f0c41535a0c98c958cb4c896cc62'/>
<id>d659364295f6f0c41535a0c98c958cb4c896cc62</id>
<content type='text'>
In Unix/DynamicLibrary.inc, it was already known that Cygwin required
use of `RTLD_DEFAULT` as the `Handle` parameter to `DLSym` to search all
modules for a symbol. Unfortunately, RTLD_DEFAULT is defined as NULL, so
the existing checks of the `Process` handle meant `DLSym` would never be
called on Cygwin. Use the existing `&amp;Invalid` sentinel instead of
`nullptr` for the `Process` handle.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In Unix/DynamicLibrary.inc, it was already known that Cygwin required
use of `RTLD_DEFAULT` as the `Handle` parameter to `DLSym` to search all
modules for a symbol. Unfortunately, RTLD_DEFAULT is defined as NULL, so
the existing checks of the `Process` handle meant `DLSym` would never be
called on Cygwin. Use the existing `&amp;Invalid` sentinel instead of
`nullptr` for the `Process` handle.</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Call hash_combine_range with ranges (NFC) (#143225)</title>
<updated>2025-06-07T05:55:19+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-06-07T05:55:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=477f9f6d92a49a69b26c44cf08234f2eb68c900a'/>
<id>477f9f6d92a49a69b26c44cf08234f2eb68c900a</id>
<content type='text'>
We can now invoke hash_combine_range with a range.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We can now invoke hash_combine_range with a range.</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC][ADT/Support] Add {} for else when if body has {} (#140758)</title>
<updated>2025-05-21T20:19:09+00:00</updated>
<author>
<name>Rahul Joshi</name>
<email>rjoshi@nvidia.com</email>
</author>
<published>2025-05-21T20:19:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a76bf4da53182baace54fd69f9d38fc10e6b8e85'/>
<id>a76bf4da53182baace54fd69f9d38fc10e6b8e85</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm][Support][Windows] Fix slash in path for remove_directories (#121448)</title>
<updated>2025-01-02T17:32:42+00:00</updated>
<author>
<name>Jinsong Ji</name>
<email>jinsong.ji@intel.com</email>
</author>
<published>2025-01-02T17:32:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5de7af4b9f05c7a9fb3775f45627b50aba47869b'/>
<id>5de7af4b9f05c7a9fb3775f45627b50aba47869b</id>
<content type='text'>
Before 925471ed903dad871042d7ed0bab89ab6566a564 remove_directories
supports path with slash (instead of backslash).
The ILCreateFromPathW in new implementation requires backslash path,
so the call to remove_directories will fail if the path contains slash.

This is to normalize the path to make sure remove_directories still
support path with slash as well.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before 925471ed903dad871042d7ed0bab89ab6566a564 remove_directories
supports path with slash (instead of backslash).
The ILCreateFromPathW in new implementation requires backslash path,
so the call to remove_directories will fail if the path contains slash.

This is to normalize the path to make sure remove_directories still
support path with slash as well.</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm][Support][Windows] Refactored remove_directories() w/o CComPtr and atlbase.h (#119843)</title>
<updated>2024-12-13T12:59:31+00:00</updated>
<author>
<name>Dmitry Vasilyev</name>
<email>dvassiliev@accesssoftek.com</email>
</author>
<published>2024-12-13T12:59:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d098ce0ec9e4dddb494f1f61ff36921dd4ce5f8e'/>
<id>d098ce0ec9e4dddb494f1f61ff36921dd4ce5f8e</id>
<content type='text'>
This is the update of #118677. This patch fixes building with mingw.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is the update of #118677. This patch fixes building with mingw.</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm][Support][Windows] Avoid crash calling remove_directories() (#118677)</title>
<updated>2024-12-12T07:17:54+00:00</updated>
<author>
<name>Dmitry Vasilyev</name>
<email>dvassiliev@accesssoftek.com</email>
</author>
<published>2024-12-12T07:17:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=925471ed903dad871042d7ed0bab89ab6566a564'/>
<id>925471ed903dad871042d7ed0bab89ab6566a564</id>
<content type='text'>
We faced an unexpected crash in SHELL32_CallFileCopyHooks() on the buildbot 
[lldb-remote-linux-win](https://lab.llvm.org/staging/#/builders/197/builds/1066).
The host is Windows Server 2022 w/o any 3rd party shell extensions. See #118032 for more details.
Based on [this article](https://devblogs.microsoft.com/oldnewthing/20120330-00/?p=7963).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We faced an unexpected crash in SHELL32_CallFileCopyHooks() on the buildbot 
[lldb-remote-linux-win](https://lab.llvm.org/staging/#/builders/197/builds/1066).
The host is Windows Server 2022 w/o any 3rd party shell extensions. See #118032 for more details.
Based on [this article](https://devblogs.microsoft.com/oldnewthing/20120330-00/?p=7963).</pre>
</div>
</content>
</entry>
<entry>
<title>[Support] Include Support/thread.h before api implementations (#111175)</title>
<updated>2024-10-10T04:45:29+00:00</updated>
<author>
<name>Thomas Fransham</name>
<email>tfransham@gmail.com</email>
</author>
<published>2024-10-10T04:45:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9093ba9f7ee58ccf62e58487a5028707a248c0b7'/>
<id>9093ba9f7ee58ccf62e58487a5028707a248c0b7</id>
<content type='text'>
This header was included after the implementations to work around an
issue with FreeBSD, however, , this causes some issues when
dllexport\explicit visibility
attributes will be added to the headers on Windows, since the
definitions need to see the declarations for the attributes to apply.

This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
windows.

---------

Co-authored-by: Tom Stellard &lt;tstellar@redhat.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This header was included after the implementations to work around an
issue with FreeBSD, however, , this causes some issues when
dllexport\explicit visibility
attributes will be added to the headers on Windows, since the
definitions need to see the declarations for the attributes to apply.

This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
windows.

---------

Co-authored-by: Tom Stellard &lt;tstellar@redhat.com&gt;</pre>
</div>
</content>
</entry>
</feed>
