openslx-ng/ipxe.git/src/Makefile.housekeeping, branch v1.20.1

[build] Move predefined all-drivers build shortcut to Makefile

2019-08-02T10:00:43+00:00

The (very approximate) split between Makefile.housekeeping and Makefile is that the former provides mechanism and the latter provides policy. Provide a section within Makefile as a home for predefined build shortcuts such as the existing all-drivers build. Signed-off-by: Michael Brown

[build] Do not apply WORKAROUND_CFLAGS for host compiler

2019-07-22T13:51:28+00:00

The WORKAROUND_CFLAGS list is constructed based on running tests on the target compiler, and the results may not be valid for the host compiler. The only relevant workaround required for the host compiler is -Wno-stringop-truncation, which is needed to avoid a spurious compiler warning for a totally correct usage of strncpy() in util/elf2efi.c. Duplicating the workaround tests for the host compiler is messy, as is conditionally applying __attribute__((nonstring)). Fix instead by disapplying WORKAROUND_CFLAGS for the host compiler, and using memcpy() with an explicitly calculated length instead of strncpy() in util/elf2efi.c. Reported-by: Ignat Korchagin Reported-by: Christopher Clark Signed-off-by: Michael Brown

[build] Workaround compilation error with gcc 9.1

2019-07-22T10:07:13+00:00

Compiling with gcc 9.1 generates lots of "taking address of packed member of ... may result in an unaligned pointer value" warnings. Some of these warnings are genuine, and indicate correctly that parts of iPXE currently require the CPU (or runtime environment) to support unaligned accesses. For example: the TCP/IP receive data path will attempt to access 32-bit fields that may not be aligned to a 32-bit boundary. Other warnings are either spurious (such as when the pointer is to a variable-length byte array, which can have no alignment requirement anyway) or unhelpful (such as when the pointer is used solely to provide a debug colour value for the DBGC() macro). There appears to be no easy way to silence the spurious warnings. Since the ability to perform unaligned accesses is already a requirement for iPXE, work around the problem by silencing this class of warnings. Signed-off-by: Valentine Barshak Modified-by: Michael Brown Signed-off-by: Michael Brown

[build] Use positive-form tests when checking for supported warnings

2018-07-08T17:17:18+00:00

Some versions of gcc seem to silently accept an attempt to disable an unrecognised warning (e.g. via -Wno-stringop-truncation) but will then report the unrecognised warning if any other error occurs during the build, resulting in a potentially misleading error message. Avoid this potential confusion by using the positive-form tests in order to determine the workaround CFLAGS. Signed-off-by: Michael Brown

[build] Disable gcc stringop-truncation warnings

2018-07-07T18:46:16+00:00

The gcc 8 compiler introduces a warning for certain string manipulation functions, flagging usages which _may_ not be intended. An audit of the iPXE sources indicates all usages of strncat and strncpy are as intended, so the warnings currently issued are not helpful, especially if warnings are considered errors. Fix by detecting gcc's support for -Wno-stringop-truncation and, if detected, using that option to avoid the warning. Signed-off-by: Bruce Rogers Modified-by: Michael Brown Also-fixed-by: Christian Hesse Also-fixed-by: Roman Kagan Also-fixed-by: Bernhard M. Wiedemann Also-fixed-by: Olaf Hering Signed-off-by: Michael Brown

[build] Exclude selected directories from Secure Boot builds

2017-09-18T13:38:12+00:00

When submitting binaries for UEFI Secure Boot signing, certain known-dubious subsystems (such as 802.11 and NFS) must be excluded from the build. Mark the directories containing these subsystems as insecure, and allow the build target to include an explicit "security flag" (a literal "-sb" appended to the build platform) to exclude these source directories from the build process. For example: make bin-x86_64-efi-sb/ipxe.efi will build iPXE with all code from the 802.11 and NFS subsystems excluded from the build. Signed-off-by: Michael Brown

[profile] Allow profiling to be globally enabled or disabled

2016-07-05T12:49:51+00:00

As with assertions, profiling is enabled for objects built with any debug level (including an explicit debug level of zero). Allow profiling to be globally enabled or disabled by adding PROFILE=1 or PROFILE=0 respectively to the build command line. Signed-off-by: Michael Brown

[libc] Allow assertions to be globally enabled or disabled

2016-07-05T12:28:51+00:00

Assertions are enabled for objects built with any debug level (including an explicit debug level of zero). It is sometimes useful to be able to enable assertions across all objects; this currently requires manually hacking include/assert.h. Allow assertions to be globally enabled by adding ASSERT=1 to the build command line. For example: make bin/8086100e.mrom ASSERT=1 Similarly, allow assertions to be globally disabled by adding ASSERT=0 to the build command line. If no ASSERT=... is specified on the build command line, then only objects mentioned in DEBUG=... will have assertions enabled (as is currently the case). Note than globally enabling assertions imposes a relatively heavy runtime penalty, primarily due to the various sanity checks performed by list_add(), list_for_each_entry(), etc. Signed-off-by: Michael Brown

[debug] Allow debug messages to be initially disabled at runtime

2016-07-05T11:34:15+00:00

Extend the DEBUG=... syntax to allow debug messages to be compiled in but disabled by default. For example: make bin/undionly.kpxe DEBUG=netdevice:3:1 would compile in the messages as for DEBUG=netdevice:3, but would set the debug level mask so that only the DEBUG=netdevice:1 messages would be displayed. This allows for external code to selectively enable the additional debug messages at runtime, without being overwhelmed by unwanted initial noise. For example, a developer of a new protocol may want to temporarily enable tracing of all packets received: this can be done by building with DEBUG=netdevice:3:1 and using // temporarily enable per-packet messages DBG_ENABLE_OBJECT ( netdevice, DBGLVL_EXTRA ); ... // disable per-packet messages DBG_DISABLE_OBJECT ( netdevice, DBGLVL_EXTRA ); Note that unlike the usual DBG_ENABLE() and DBG_DISABLE() macros, DBG_ENABLE_OBJECT() and DBG_DISABLE_OBJECT() will not be removed via dead code elimination if debugging is disabled in the specified object. In particular, this means that using either of these macros will always result in a symbol reference to the specified object. Signed-off-by: Michael Brown

[build] Remove unnecessary dependency on zlib

2016-05-02T22:09:49+00:00

The dependency on zlib seems to have been introduced in commit 3dd7ce1 ("[efi] Allow building with non-system libbfd") as an indirect requirement of either libbfd or libiberty when building on Mac OS X. Since we no longer use either of these libraries, remove the unnecessary link against zlib. Signed-off-by: Michael Brown