BaseTools has been duplicating and adapting code that is defined in
MdePkg and MdeModulePkg. This leads to desync issues where the same
symbols may be backed by different functions with slightly different
semantics and also fixes that apply only to BaseTools or only to MdePkg
and MdeModulePkg.
To address these issues, update BaseTools/Source/C to utilize the code
from MdePkg and MdeModulePkg.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
BaseTools has been duplicating and adapting code that is defined in
MdePkg and MdeModulePkg. This leads to desync issues where the same
symbols may be backed by different functions with slightly different
semantics and also fixes that apply only to BaseTools or only to MdePkg
and MdeModulePkg.
To address these issues, update BaseTools/Source/C to utilize the code
from MdePkg and MdeModulePkg.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was
added by having users specify "make CXX=llvm" when building BaseTools.
The Makefile then sees that and sets CC=$(CLANG_BIN)clang and
CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and
'clang++' exist and for example aren't named 'clang-17' and
'clang++-17'. Also, it's an unusual way of specifying the compiler,
since many users will expect to be able to override CC and CXX on the
make command line.
Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC
and BUILD_CXX) and using the standard name 'LDFLAGS' instead of
'LFLAGS'. This allows clang to be used by running
'make -C BaseTools CC=clang CXX=clang++'.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was
added by having users specify "make CXX=llvm" when building BaseTools.
The Makefile then sees that and sets CC=$(CLANG_BIN)clang and
CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and
'clang++' exist and for example aren't named 'clang-17' and
'clang++-17'. Also, it's an unusual way of specifying the compiler,
since many users will expect to be able to override CC and CXX on the
make command line.
Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC
and BUILD_CXX) and using the standard name 'LDFLAGS' instead of
'LFLAGS'. This allows clang to be used by running
'make -C BaseTools CC=clang CXX=clang++'.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
When checking the version in DevicePath's Makefile, use BUILD_CC instead
of assuming "gcc". BUILD_CC is set in header.makefile and is the
compiler that will actually be used to build DevicePath. It defaults to
"gcc", but may be overridden.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
In an effort to clean the documentation of the above
package, remove duplicated words.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
On macOS, /usr/bin/gcc is clang, and so doesn't have
the -Wno-error=stringop-overflow flag that was added
for gcc 12.
Update the GNUmakefile for DevicePath to skip setting
that on macOS.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
In function ?SetDevicePathEndNode?,
inlined from ?FileDevicePath? at DevicePathUtilities.c:857:5:
DevicePathUtilities.c:321:3: error: writing 4 bytes into a region of size 1 [-Werror=stringop-overflow=]
321 | memcpy (Node, &mUefiDevicePathLibEndDevicePath, sizeof (mUefiDevicePathLibEndDevicePath));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from UefiDevicePathLib.h:22,
from DevicePathUtilities.c:16:
../Include/Protocol/DevicePath.h: In function ?FileDevicePath?:
../Include/Protocol/DevicePath.h:51:9: note: destination object ?Type? of size 1
51 | UINT8 Type; ///< 0x01 Hardware Device Path.
| ^~~~
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Currently the PCD Value only support 13 Guid,When use more 13 pcd will cause the build tool fail,
Need calculate the required memory,then allocate it.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3718
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Xiaolu Jiang <xiaolu.jiang@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Replace the default size limit of IsDevicePathValid() with a value
that does not depend on the native word size of the build host.
4 GiB seems sufficient as the upper bound of a device path handled
by UEFI.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Replace invocations of StrHexToUintn() with StrHexToUint64(), so
that we can drop the former.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Per UEFI spec, FibreEx.WWN, FibreEx.Lun, SasEx.Address, SasEx.Lun
and iSCSI.Lun are all 8-byte array with byte #0 in the left.
It means "0102030405060708" should be converted to:
UINT8[8] = {01, 02, 03, 04, 05, 06, 07, 08}
or UINT64 = {0807060504030201}
Today's implementation wrongly uses the reversed order.
The patch fixes this issue by using StrHexToBytes().
Copy this solution from MdePkg Hash version d0196be.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
If protocol string is not specified, default TCP(0) should be used.
Today's implementation wrongly sets to 1 for this case.
Copy the fix solution from MdePkg Hash version e6c80aea.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Currently "BaseTools/Source/C/DevicePath/DevicePath.c" fails to build with
GCC48:
> DevicePath.c: In function 'print_mem':
> DevicePath.c:109:5: error: 'for' loop initial declarations are only
> allowed in C99 mode
> for (size_t i=0; i<n; i++) {
> ^
> DevicePath.c:109:5: note: use option -std=c99 or -std=gnu99 to compile
> your code
In addition, the print_mem() function does not conform to the edk2 coding
style:
- we use CamelCase and no underscores in identifiers,
- the types and type qualifiers should follow the edk2 style,
- initialization as part of definition is forbidden for local variables.
Clean these up.
While updating the print_mem()/PrintMem() call sites, also remove the
superfluous parentheses around the second argument.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Fixes: 7dbc50bd244d95fdc1741b9cfc561f0bfd724de1
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
Use C code parse device path to output hex string, and Python
run command when PCD Value need device path parse.
https://bugzilla.tianocore.org/show_bug.cgi?id=541
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com>
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
