[build] Fix erroneous object name in version object
Commit 8290a95 ("[build] Expose build timestamp, build name, and
product names") introduced a regression in the build process which
resulted in broken final binaries which had names based on object
files (e.g. "undionly.kpxe" or "intel.rom") rather than on device IDs
(e.g. "8086100e.mrom").
The underlying problem is the -DOBJECT=<name> macro which is used to
generate the obj_<name> symbols used to select objects required for
the final binary. The macro definition is derived from the initial
portion (up to the first dot) of the object being built. In the case
of e.g. undionly.kpxe.version.o, this gives -DOBJECT=undionly. This
results in undionly.kpxe.version.o claiming to be the "undionly"
object; the real "undionly" object will therefore never get dragged in
to the build.
Fix by renaming $(BIN)/%.version.o to $(BIN)/version.%.o, so that the
object is always built with -DOBJECT=version (as might be expected,
since it is built from core/version.c).
Final binaries which have names based on device IDs (such as
"8086100e.mrom") are not affected by this problem, since the object
name "8086100e" will not conflict with that of the underlying "intel"
object.
This problem was not detected by the per-commit smoke testing
procedure, which happens to use the binary bin/8086100e.mrom.
Reported-by: Christian Hesse <list@eworm.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Expose build timestamp, build name, and product names
Expose the build timestamp (measured in seconds since the Epoch) and
the build name (e.g. "rtl8139.rom" or "ipxe.efi"), and provide the
product name and product short name in a single centralised location.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[debug] Allow debug message colours to be customised via DBGCOL=...
When multiple iPXE binaries are running concurrently (e.g. in the case
of undionly.kpxe using an underlying iPXE driver via the UNDI
interface) it would be helpful to be able to visually distinguish
debug messages from each binary.
Allow the range of debug colours used to be customised via the
DBGCOL=... build parameter. For example:
# Restrict to colours 31-33 (red, green, yellow)
make DBGCOL=31-33
# Restrict to colours 34-36 (blue, magenta, cyan)
make DBGCOL=34-36
Signed-off-by: Michael Brown <mcb30@ipxe.org>
If iPXE is used as a git submodule then the ../.git/index file will
not exist, and the build will fail. Fix by checking that the git
index file exists before adding it as a build dependency.
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 8540300 ("[build] Disable ccache for all relevant build
targets") attempted to generalise the rule for $(BIN)/version.o to
$(BIN)/version.% in order to apply the dependency to all relevant
build targets (debug objects, assembly listings, etc).
This generalisation appears to work for the ccache override
directives, but seems to cause make (at least, GNU make 4.0) to simply
ignore the dependency upon the git index.
Since version.c contains only some string constants, there is unlikely
to be a substantive need for its debug objects, assembly listings,
etc. Restore the previous form of the dependency and accept that
hypothetical builds with e.g. DEBUG=version will not be handled
correctly.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for an explicit debug level of zero, which will enable
assertions and profiling (i.e. anything controlled by NDEBUG) without
generating any debug messages.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Generalise X.509 cache to a full certificate store
Expand the concept of the X.509 cache to provide the functionality of
a certificate store. Certificates in the store will be automatically
used to complete certificate chains where applicable.
The certificate store may be prepopulated at build time using the
CERT=... build command line option. For example:
make bin/ipxe.usb CERT=mycert1.crt,mycert2.crt
Certificates within the certificate store are not implicitly trusted;
the trust list is specified using TRUST=... as before. For example:
make bin/ipxe.usb CERT=root.crt TRUST=root.crt
This can be used to embed the full trusted root certificate within the
iPXE binary, which is potentially useful in an HTTPS-only environment
in which there is no HTTP server from which to automatically download
cross-signed certificates or other certificate chain fragments.
This usage of CERT= extends the existing use of CERT= to specify the
client certificate. The client certificate is now identified
automatically by checking for a match against the private key. For
example:
make bin/ipxe.usb CERT=root.crt,client.crt TRUST=root.crt KEY=client.key
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Add dependency of generated files upon Makefile
Ensure that any generated files (such as DER forms of X.509
certificates) are rebuilt if the Makefile changes.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Disable ccache for all relevant build targets
The build process currently attempts to disable ccache for files using
the .incbin directive, but the rule fails to apply to anything beyond
the simple object target. Fix by applying to all relevant build
targets (including debug objects, assembly listings, and so on).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
OpenBSD 5.4 seems to generate dynamically linked binaries by default,
which breaks our build process. Fix by forcing the linker to always
create static binaries.
Reported-by: Jiri B <jirib@devio.us>
Tested-by: Jiri B <jirib@devio.us>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Our use of --gc-sections causes the linker to discard the symbols
defined by FILE_LICENCE(), meaning that the resulting licence
determination is incomplete.
We must use the KEEP() directive in the linker script to force the
linker to not discard the licence symbols. Using KEEP(*(COMMON))
would be undesirable, since there are some symbols in COMMON which we
may wish to discard.
Fix by placing symbols defined by PROVIDE_SYMBOL() (which is used by
FILE_LICENCE()) into a special ".provided" section, which we then mark
with KEEP(). All such symbols are zero-length, so there is no cost in
terms of the final binary size.
Since the symbols are no longer in COMMON, the linker will reject
symbols with the same name coming from multiple objects. We therefore
append the object name to the licence symbol, to ensure that it is
unique.
Reported-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When the $(eval) function is available (in GNU make >= 3.80), we can
evaluate many of the dynamically-generated Makefile rules directly.
This avoids generating a few hundred Makefile fragments in the
filesystem, and so speeds up the build process.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Linker table entries must be non-static in order to avoid being
completely optimised away by some versions of gcc. Use -Wno-decl to
prevent sparse from warning about these, since the alternative would
be to litter the code with otherwise unnecessary "extern"
declarations.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
sparse seems to have problems finding compiler.h when specified as
"-include compiler.h"; one possible explanation is that it ignores the
include path. Fix by using "-include include/compiler.h".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The version number string is currently updated only if version.o
happens to be rebuilt due to changes in its dependencies. Add a
dependency upon the git index, so that the version number is updated
after any checkout.
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Using -fno-dwarf2-cfi-asm is not sufficient to prevent the .eh_frame
section from being generated on newer versions of gcc. Add
-fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables;
this is sufficient to inhibit the .eh_frame section on gcc 4.7.1.
This does not affect the overall binary size, but does fix the numbers
reported by "size" for individual object files.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Rename KEY= to PRIVKEY= and "key" to "privkey"
The setting name "key" conflicts with the setting name "key" already
in use by the 802.11 code. Resolve the conflict by renaming the newer
setting to "privkey".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Use $(xxx_DEPS) for additional dependency information
Some objects (embedded.o, rootcert.o, and clientcert.o) define
additional dependencies on external files, using syntax such as:
$(BIN)/clientcert.o : $(CERT_LIST)
This dependency can be missed when using debug builds. For example,
if DEBUG=clientcert is used, then the relevant object is
$(BIN)/clientcert.dbg1.o rather than $(BIN)/clientcert.o.
Fix by adding dependencies to $(clientcert_DEPS) instead:
clientcert_DEPS += $(CERT_LIST)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Allow a client certificate to be specified at build time
Allow a client certificate and corresponding private key to be
specified at build time using the syntax
make CERT=/path/to/certificate KEY=/path/to/key
The build process uses openssl to convert the files into DER format,
and includes them within the client certificate store in
clientcert.c. The build process will prompt for the private key
password if applicable.
Note that the private key is stored unencrypted, and so the resulting
iPXE binary (and the temporary files created during the build process)
should be treated as being equivalent to an unencrypted private key
file.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Allow trusted root certificates to be specified at build time
Allow trusted root certificates to be specified at build time using
the syntax
make TRUST=/path/to/certificate1,/path/to/certificate2,...
The build process uses openssl to calculate the SHA-256 fingerprints
of the specified certificates, and adds them to the root certificate
store in rootcert.c. The certificates can be in any format understood
by openssl.
The certificates may be server certificates or (more usefully) CA
certificates.
If no trusted certificates are specified, then the default "iPXE root
CA" certificate will be used.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Avoid using -ffunction-sections on some older versions of gcc
Some older versions of gcc issue a warning if -ffunction-sections is
used in combination with -g (gcc bug #18553). Inhibit
-ffunction-sections when building with such a version of gcc.
Reported-by: zhengwei <zw111_2001@126.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Accept EMBED=... as a synonym for EMBEDDED_IMAGE=...
Make the build command line less cumbersome by accepting
make DEBUG=int13 EMBED=test.ipxe
rather then
make DEBUG=int13 EMBEDDED_IMAGE=test.ipxe
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Run parserom.pl only on potential driver files
PCI_ROM() and ISA_ROM() macros occur only within driver files.
Running parserom.pl on non-driver files is therefore redundant.
Skip running parserom.pl on any files outside a "drivers" directory.
This reduces the time taken to generate build rules and dependencies
after a "make veryclean" by around 12%.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Refuse to attempt building with the GNU gold linker
GNU gold (part of newer binutils builds) does not appear to be
designed to support generic linker functionality, since its source
code contains several Linux-specific hard-coded assumptions about the
layout of ELF binaries. Attempting to build iPXE using GNU gold will
generally cause some kind of "linker internal error".
Provide an explicit error message suggesting the use of GNU ld
instead.
Reported-by: Chris Hills <chaz@chaz6.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Avoid spurious address comparison warnings in gcc 4.6
A construction such as "assert ( ptr != NULL )" seems to trigger a
false positive warning in gcc 4.6 if the value of "ptr" is known at
compile-time to be non-NULL. Use -Wno-address to inhibit this
warning.
Reported-by: Ralph Giles <giles@thaumas.net>
Tested-by: Ralph Giles <giles@thaumas.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The keymap files, though autogenerated, are checked in to version
control and should be considered as source files. They should never
be automatically rebuilt.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Inspired by LILO's keytab-lilo.pl, genkeymap.pl uses "loadkeys -b" to
obtain a Linux keyboard map, and generates a file keymap_xx.c in
hci/keymap.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some binutils versions will drag in an object to satisfy the entry
symbol; some won't. Try to cope with this exciting variety of
behaviour by ensuring that all entry symbols are unique.
Remove the explicit inclusion of the prefix object on the linker
command line, since the entry symbol now provides all the information
needed to identify the prefix.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use -ffunction-sections, -fdata-sections, and --gc-sections to
automatically prune out any unreferenced sections.
This saves around 744 bytes (uncompressed) from the rtl8139.rom build.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[legal] Ignore config/local header files for licensing purposes
The config/local/*.h files are expected to be empty in most cases.
This should not cause a licence determination to fail.
Fix by ignoring config/local/*.h for licensing purposes.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When using binutils 2.20, it seems to be necessary to add -ldl to link
against -lbfd.
Reported-by: Duane Voth <duanev@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Properly handle multiple goals per BIN directory
When building multiple targets per BIN with multiple jobs, for
example:
make -j16 bin-i386-efi/ipxe.efi{,drv,rom} bin-x86_64-efi/ipxe.efi{,drv,rom}
we would invoke a make subprocess for each goal in parallel resulting
in multiple makes running in a single BIN directory. Fix by grouping
goals per BIN directory and invoking only one make per BIN. It is
both safer and faster.
Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Currently, if elf2efi.c is compiled using a 32-bit HOST_CC, then the
resulting elf2efi64 binary will generate 32-bit EFI binaries instead
of 64-bit EFI binaries.
The problem is that elf2efi.c uses the MDE_CPU_* definitions to decide
whether to output a 32-bit or 64-bit PE binary. However, MDE_CPU_*
gets defined in ProcessorBind.h, depending on the compiler's target
architecture. Overriding them on the command line doesn't work in the
expected way, and you can end up in cases where both MDE_CPU_IA32 and
MDE_CPU_X64 are defined.
Fix by using a separate definition, EFI_TARGET_IA32/EFI_TARGET_X64,
which is specified only on the command line.
Signed-off-by: Geoff Lywood <glywood@vmware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown