This makes us use CFLAGS when trying to find libgcc, so we don't get the
one with the wrong endian or float ABI.
Signed-off-by: Peter Jones <pjones@redhat.com>
Currently they'll exclude e.g. inc/x64/ by accident; this makes it only
apply to the top level.
Also adds vim temp files to the ignore list.
Signed-off-by: Peter Jones <pjones@redhat.com>
This is ascii order but with upper and lower case letters mixed, so
things like 'X' and 'x' that use fallthrough still stay together.
Signed-off-by: Peter Jones <pjones@redhat.com>
Since crt0 and our linker scripts are now in a subdirectory, there's no
need to make them named differently in the installed machine. This
renames them to crt0.o and efi.lds .
Signed-off-by: Peter Jones <pjones@redhat.com>
This makes it possible to install all the output on the same machine for
cross-builds. This also adds "install_compat", which uses the previous
paths.
Signed-off-by: Peter Jones <pjones@redhat.com>
This makes the normal DESTDIR= variable work on the command line, and
makes relative paths always relative to the top-level directory.
Signed-off-by: Peter Jones <pjones@redhat.com>
Currently on x64 we manually build a dummy .reloc table entry by using a
symbol in .text and subtracting its address from another symbol that's
inside the .reloc section. On ia32 we just use its location. In either
case, if the linker puts either section in a location we're not
expecting, the .reloc table winds up having invalid values, and the PE
loader will fail to load the binary.
This changes it to be two symbols that are both in .text, making the
result unrelated to the section order or location.
It's not clear to me that these .reloc entries are actually necessary at
all, but I'm going to leave them in place for now, in case they are.
Signed-off-by: Peter Jones <pjones@redhat.com>
This makes our "make clean" commands show what they've /removed/, rather
than what the shell code that will be run is.
It also consolidates our list of arches into an ARCHES variable defined
in Make.defaults
Signed-off-by: Peter Jones <pjones@redhat.com>
Right now whenever we have shell commands with loops, errors in the
middle are accidentally ignored, and make continues to process commands.
This adds "set -e" to all of those, so they'll propagate back up.
Signed-off-by: Peter Jones <pjones@redhat.com>
This makes setup and teardown functions defined with
__attribute__((__constructor__) and __attribute__((__destructor__)) work
in normal circumstances in EFI binaries.
A couple of notes:
- it implements both the old-style .ctors/.dtors methods and the newer
style .init_array/.fini_array ELF constructor and destructor arrays,
processed in the order:
.init_array[]
.ctors[]
efi_main()
.dtors[]
.fini_array[]
- Destructors will only be called if efi_main() exits using "return";
any call to Exit() will still longjmp() past them.
- InitializeLib() has already been called before constructors run, so
they don't need to call it (and neither does anything else.) For
compatibility, it has been altered so calling it more than once is
safe.
- No attempt is made to handle any constructor or destructor with a
prototype other than "void func(void);", but note that InitializeLib
has been called, so LibImageHandle, ST, BS, and RT are set.
- The init_array/ctor/dtor/fini_array lists aren't the using the GNU
"CONSTRUCTOR" output section command, so they don't start with a size.
- The lists are individually sorted during the link stage via
SORT_BY_NAME() in the linker script.
- The default (empty) init_array/ctor/dtor/fini_array lists are padded
out to 8-byte alignment with ".p2align 3, 0", and each list always has
at least one ".long 0" at the end of it (even if it's completely
empty). As a result, they can have NULLs that need to be skipped.
The sections they're in are mergeable, so the NULLs don't have to be
exclusively at the end.
- The ia64 and mips64el arches have not been tested.
Signed-off-by: Peter Jones <pjones@redhat.com>
These files are all edk2-like makefile snippets, and we don't use any of
them for anything. They've also got DOS line endings and things like
that.
This patch just gets rid of them.
Signed-off-by: Peter Jones <pjones@redhat.com>
Some of these files will be removed in a later patch, but they need to
stay in .gitattributes until after the next release, because they make
patch application break in weird ways.
Signed-off-by: Peter Jones <pjones@redhat.com>
Coverity added a new kind of check, and it noticed some minor errors
with some types in two of the apps here, both of the same form:
1. gnu-efi-3.0.6/apps/lfbgrid.c:91: overflow_before_widen: Potentially
overflowing expression "info->VerticalResolution *
info->PixelsPerScanLine" with type "unsigned int" (32 bits, unsigned) is
evaluated using 32-bit arithmetic, and then used in a context that
expects an expression of type "UINTN" (64 bits, unsigned).
1. gnu-efi-3.0.6/apps/bltgrid.c:67: overflow_before_widen: Potentially
overflowing expression "info->VerticalResolution *
info->HorizontalResolution" with type "unsigned int" (32 bits, unsigned)
is evaluated using 32-bit arithmetic, and then used in a context that
expects an expression of type "UINTN" (64 bits, unsigned).
This resolves both issues.
Signed-off-by: Peter Jones <pjones@redhat.com>
Always use x64/X64 and aa64/AA64 unless the toolchain cares about
"x86_64" or whatnot.
Note that we still have mips64el as an arch name, which is not actually
defined in the UEFI specs.
Signed-off-by: Peter Jones <pjones@redhat.com>
* __STDC_VERSION__ is undefined when headers are called from C++
code resulting in not using stdint.h and efibind.h
"making a guess" on what they are. extern "C" will not define
__STDC_VERSION__.
* Always leverage stdint.h on C++.
* Honestly, gnu-efi should always use stdint.h, or find a better
way to detect it. (or platforms without it need to catch up to 2007)
Breaks gcc builds with '-nostdinc' flag.
The fix in 1a53d8f88a
(Fix for problem with undeclared intptr_t type), which is also merged
fixes the same problem, without causing breakage.
This reverts commit 6335e5c697.
because of a "make" builtin rule. This breaks make -r, and it is an
inefficient way to build, at least for multiple files.
I have made a git tree which includes a patch for this problem,
and also forces -r by adding it to MAKEFLAGS:
git://git.zytor.com/users/hpa/gnu-efi.git make-r-fixes
Signed-off-by: H. Peter Anvin <hpa@users.sourceforge.net>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
Make.rules is not complete; in particular it lacks a %.o: %.S rule.
This happens to work due to the builtin make rule to that effect. but
building with make -r, or building as a sub-make of an environment that
uses make -r (or MAKEFLAGS += -r) causes it to break.
In general, make -r is strongly preferred, and Make.rules seems to have
been created explicitly to support this.
To further complicate things, the rule %.S: %.c causes a completely
incomprehensible error message. This rule is wrong, it should be %.s:
%.c not %.S: %.c.
Finally, the rule %.E: %.c is normally %.i: %.c; .i is the normal
extension for preprocessed C source. The equivalent rule for assembly is
%.s: %.S.
Signed-off-by: H. Peter Anvin <hpa@users.sf.net>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
When building gnu-efi with old compilers with pre C90 compilers:
In file included from gnu-efi-3.0.9/lib/../inc/efilib.h:25:0,
from gnu-efi-3.0.9/lib/lib.h:24,
from gnu-efi-3.0.9/lib/dpath.c:25:
gnu-efi-3.0.9/lib/dpath.c: In function 'FileDevicePath':
gnu-efi-3.0.9/lib/../inc/efilink.h:145:47: error: 'intptr_t' undeclared (first use in this function)
#define EFI_FIELD_OFFSET(TYPE,Field) ((UINTN)(intptr_t)(&(((TYPE *) 0)->Field)))
Problem introduced with commit a46a62b12b
(Fix some types gcc doesn't like).
Avoid this by adding intptr_t (and uintptr_t) typedefs for builds that does
not include stdint.h.
Signed-off-by: Esben Haabendal <esben@esben1.localdomain>
On couple of locations in runtime string library (rtstr.c)
there are calls to non-runtime variant of StrLen function.
* Another issue is with formatting 1394 paths.
The F1394_DEVICE_PATH::Guid is formatted as %g, but 1394
GUID is 8 byte integer, not EFI_GUID and therefore should
be formatted as e.g. %016lx (as edk2 does).
* Beyond what's mentioned above, changed the format of the
harddrive path, so it's in line with edk2 format and spec
(2.7 errata A, chapter 10.6.1.6, table 102).
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
Signed-off-by: manison <manison@users.sf.net>
The arguments to SetMem() were wrong. Besides, SetMem() should start at
"Dest + Size" since "Size" will be smaller than "Len" if they are not
equal.
Signed-off-by: Gary Lin <glin@suse.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
