<feed xmlns='http://www.w3.org/2005/Atom'>
<title>Tianocore/edk2.git/BaseTools/Source, branch edk2_master</title>
<subtitle>EDK II (mirror)</subtitle>
<id>https://git.radix-linux.su/Tianocore/edk2.git/atom?h=edk2_master</id>
<link rel='self' href='https://git.radix-linux.su/Tianocore/edk2.git/atom?h=edk2_master'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/Tianocore/edk2.git/'/>
<updated>2026-01-06T06:27:41+00:00</updated>
<entry>
<title>BaseTools/Source/C/Makefiles: Detect cycle in pids</title>
<updated>2026-01-06T06:27:41+00:00</updated>
<author>
<name>Michael D Kinney</name>
<email>michael.d.kinney@intel.com</email>
</author>
<published>2026-01-01T20:50:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/Tianocore/edk2.git/commit/?id=f26760f5e20326cae5dc645a9be14928cca59ad7'/>
<id>urn:sha1:f26760f5e20326cae5dc645a9be14928cca59ad7</id>
<content type='text'>
Update _get_win32_parent_processes() to detect a
cycle in parent process ids that can cause
_get_win32_parent_processes() to never return.

If a pid cycle is detected, then return the list
of parent process ids detected up to the point
the cycle is detected.

GitHub Actions builds using windows-2025 can
reproduce this issue once in a while. It shows
up as job that runs until a timeout. If the job
is canceled, the logs show a python stack in the
loop in _get_win32_parent_processes().

Signed-off-by: Michael D Kinney &lt;michael.d.kinney@intel.com&gt;
</content>
</entry>
<entry>
<title>BaseTools/build: Add defines for Windows build environments</title>
<updated>2026-01-06T04:44:08+00:00</updated>
<author>
<name>Michael D Kinney</name>
<email>michael.d.kinney@intel.com</email>
</author>
<published>2025-12-26T18:57:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/Tianocore/edk2.git/commit/?id=a0002ddc5342c7bb34fb3a0bb87c1235c8d8821d'/>
<id>urn:sha1:a0002ddc5342c7bb34fb3a0bb87c1235c8d8821d</id>
<content type='text'>
The stuart tools automatically add -D WIN_HOST_BUILD to
edk2 build command line if a Windows build environment
is detected. This behavior is added to build.py so that
builds of the EmulatorPkg using build.py are not required
to add the option -D WIN_HOST_BUILD when building in a
Windows environment. This aligns Linux and Windows builds
of the EmulatorPkg removing the need to specify extra
defines.

In order to build the EmulatorPkg for Windows Mingw
environments, EmulatorPkg DSC/FDF files require a way
to detect if Windows Mingw environment is present.
The Windows Mingw environment can be detected if
CLANG_BIN is set and mingw32-make.exe is detected
in the CLANG_BIN directory.

If a Windows Mingw environment is detected, add
-D WIN_MINGW32_BUILD to the edk2 build command line.

Signed-off-by: Michael D Kinney &lt;michael.d.kinney@intel.com&gt;
</content>
</entry>
<entry>
<title>BaseTools/GenFw: Ignore R_*_NONE relocations on all architectures</title>
<updated>2025-12-24T10:58:20+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2025-12-15T11:41:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/Tianocore/edk2.git/commit/?id=8d0afac1d225290f5bc6948b34cf268820dab5c8'/>
<id>urn:sha1:8d0afac1d225290f5bc6948b34cf268820dab5c8</id>
<content type='text'>
The ELF psABIs for all architectures stipulate that R_*_NONE relocations
require no action at relocation time, and merely exist to declare a
dependency on a symbol in a way that cannot be conveyed by the code
itself (i.e., using an actual symbol reference). Given that EFI PE/COFF
images are always fully linked binaries, such a dependency cannot be
translated, and there are no known reasons why this would be necessary.

So instead of ignoring such relocations specifically on x86_64 only,
ignore them on all architectures when converting ELF binaries to
PE/COFF.

Fixes: #11878

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>BaseTools,UefiPayloadPkg: Replace deprecated R_AARCH64_NONE value</title>
<updated>2025-12-24T10:58:20+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2025-12-15T11:35:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/Tianocore/edk2.git/commit/?id=ddd7855a7a7d387ed8ab6cdb2d88163b7ba9e5c2'/>
<id>urn:sha1:ddd7855a7a7d387ed8ab6cdb2d88163b7ba9e5c2</id>
<content type='text'>
For nebulous reasons, the original ELF psABI deviated from common sense,
and decided to #define R_AARCH64_NONE as '256', in spite of the fact
that no other architecture uses anything other than 0x0.

This has now been fixed in the psABI, so fix it in our code as well.

Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>BaseTools: GNUMakefiles must use CMD.EXE in Windows</title>
<updated>2025-12-24T02:03:38+00:00</updated>
<author>
<name>Michael D Kinney</name>
<email>michael.d.kinney@intel.com</email>
</author>
<published>2025-12-16T20:33:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/Tianocore/edk2.git/commit/?id=79fdd2b82af96963cd38d157494df1668f16a281'/>
<id>urn:sha1:79fdd2b82af96963cd38d157494df1668f16a281</id>
<content type='text'>
Use $(OS) in all GNUMakefiles to detect if the GNUMakefile
is being used in a Windows OS. If a Windows OS is detected,
then override SHELL to use cmd.exe. This prevents make
utility from using sh.exe if sh.exe happens to be in PATH.

If sh.exe is used, then backslash (\) characters in file
paths are removed and builds break for files not found.

Signed-off-by: Michael D Kinney &lt;michael.d.kinney@intel.com&gt;
</content>
</entry>
<entry>
<title>BaseTools: Fix multiple security vulnerabilities (Defense in Depth)</title>
<updated>2025-12-22T04:53:27+00:00</updated>
<author>
<name>20000419</name>
<email>lzy00419@163.com</email>
</author>
<published>2025-12-18T08:38:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/Tianocore/edk2.git/commit/?id=7c9fd884be4e94bd4ad8e998d85bb52d6f319e72'/>
<id>urn:sha1:7c9fd884be4e94bd4ad8e998d85bb52d6f319e72</id>
<content type='text'>
Signed-off-by: 20000419 &lt;lzy00419@163.com&gt;
</content>
</entry>
<entry>
<title>BaseTools: Cap AutoGen thread count to avoid file descriptor exhaustion</title>
<updated>2025-12-03T14:11:32+00:00</updated>
<author>
<name>Ayden Meng</name>
<email>mengxiangdong@loongson.cn</email>
</author>
<published>2025-11-27T12:57:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/Tianocore/edk2.git/commit/?id=a058a2856dec7d3e837ca5034fe892c83bc8077e'/>
<id>urn:sha1:a058a2856dec7d3e837ca5034fe892c83bc8077e</id>
<content type='text'>
When the number of build threads multiplied by per-thread file
descriptor usage exceeds the system's open file descriptor limit,
some threads may fail to acquire necessary resources (e.g., pipes
or semaphores), leading to deadlocks or hangs during parallel builds.

To prevent this situation, calculate the safety upper limit of
concurrency by dividing the system's maximum file descriptor limit by
3 (An empirical value derived from balancing performance overhead
against the theoretical number of file descriptors consumed per thread).
The actual thread count is then clamped to this safe value.

Other usages of ThreadNum()—such as during actual compilation or log
queue creation—do not significantly contribute to file descriptor
consumption. Therefore, adjusting ThreadNum() globally would be
unwarranted, as it could unnecessarily restrict parallelism in stages
that are not FD-bound.

This ensures stable parallel builds even under constrained resource
limits.

Signed-off-by: Ayden Meng &lt;mengxiangdong@loongson.cn&gt;
</content>
</entry>
<entry>
<title>BaseTools: Handle file descriptor exhaustion during parallel build</title>
<updated>2025-12-03T14:11:32+00:00</updated>
<author>
<name>Ayden Meng</name>
<email>mengxiangdong@loongson.cn</email>
</author>
<published>2025-11-27T11:55:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/Tianocore/edk2.git/commit/?id=7aaf742d2dc3f188b0307544cc767e6879df9c9e'/>
<id>urn:sha1:7aaf742d2dc3f188b0307544cc767e6879df9c9e</id>
<content type='text'>
Previously, when file descriptors were exhausted in high-concurrency
builds (e.g., 512 threads with 1024 FD limit), the build would hang or
fail silently without clear indication of the root cause.

This change catches relevant OSError instances and terminates the build,
ensuring failures due to resource limits are explicit.

Signed-off-by: Ayden Meng &lt;mengxiangdong@loongson.cn&gt;
</content>
</entry>
<entry>
<title>BaseTools/VfrCompile: Minor code cleanup</title>
<updated>2025-12-03T12:29:51+00:00</updated>
<author>
<name>Mike Beaton</name>
<email>mjsbeaton@gmail.com</email>
</author>
<published>2025-11-20T07:46:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/Tianocore/edk2.git/commit/?id=53cca9ed9995abdac9fed01aa54c4bf5195f48aa'/>
<id>urn:sha1:53cca9ed9995abdac9fed01aa54c4bf5195f48aa</id>
<content type='text'>
There are no functional changes in this commit. It adds non-functional
minor code cleanups made while tracking down the bugs fixed in the
preceding commits.

 - Fix spelling 'arrary' -&gt; 'array' where it occurs in the tool code and comments.
   - When renaming ExtractFieldNameAndArrary to ExtractFieldNameAndArrayIdx,
we fix the typo and also clarify what the method does: it returns the field name
and the array index when present. Since it is always used to populate a local
variable named ArrayIdx, we stick to that spelling in the renamed method.
 - Add comment clarifying that mArrayNum holds array length (but again, don't
go for a bigger global rename).
 - Rename CVfrVarDataTypeDB::GetFieldWidth to GetFieldType. It is only used
once, and the new name correctly matches what it does.

Signed-off-by: Mike Beaton &lt;mjsbeaton@gmail.com&gt;
</content>
</entry>
<entry>
<title>BaseTools/VfrCompile: Fix null pointer deref when dumping internal types</title>
<updated>2025-12-03T12:29:51+00:00</updated>
<author>
<name>Mike Beaton</name>
<email>mjsbeaton@gmail.com</email>
</author>
<published>2025-11-18T23:18:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/Tianocore/edk2.git/commit/?id=f79cfc8eafa56dbc4619e2e764e5cf56a4babc6d'/>
<id>urn:sha1:f79cfc8eafa56dbc4619e2e764e5cf56a4babc6d</id>
<content type='text'>
Internal types such as pFormIdField, pFormSetGuidField have
no associated field type, however the Dump command assumes
that all types do. This causes null pointer dereferencing which
can be caught by sanitizers.

De facto, the field type for these types was already
dumped as &lt;null&gt;, this achieves the same safely.

Signed-off-by: Mike Beaton &lt;mjsbeaton@gmail.com&gt;
</content>
</entry>
</feed>
