Back in the past, I re-defined CHAR8 the same way UEFI defined it (on some
platforms, some of the time, in an accidentally compiler-dependent way).
This turns out to have some bad side effects in code written without
thinking about integer promotion :/. Meanwhile, some issues were
discovered with some of the string comparison functions here.
This patch addresses all of those issue, whichever types you've got.
Signed-off-by: Peter Jones <pjones@redhat.com>
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>
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>
Back in the past, I made CHAR8 and CHAR16 work the way it does in
edk2... well, in some edk2 tree, for some arch, and accidentally
dependent on some compiler-defined types that depend on runtime choices
more than intended.
This patch makes it /always/ the same thing edk2 defines it as, without
depending on __CHAR16_TYPE__ or __WCHAR_TYPE__, and also uses CHAR16
everywhere instead of sometimes using WCHAR. We still need
-fshort-wchar, of course, for L'' and L"".
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>
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>
Having to add specific arch include paths and then <gnu-efi>/lib
to be able to use gnu-efi in an application is annoying.
This patch ensures that the library itself takes care of including
the relevant headers, and that one needs only to add <gnu-efi>/inc
in their include path to be able to use gnu-efi.
Per https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/PrintLib.h
AsciiPrint() is the official name of APrint() so declare it as such and define
an APrint alias for compatibility.
Also add an AsciiVSPrint() to print a formatted ASCII string to a buffer using
a va_list. AsciiPrint() too is defined in EDK2's PrintLib.h, though our implementation
just invokes the Unicode version and then converts the buffer to ASCII.
The __builtin_va_###() intrinsics apply only to GCC-like compilers and
MSVC's <stdarg.h> works just fine with gnu-efi.
Without this patch, one has to define GNU_EFI_USE_EXTERNAL_STDARG to
make gnu-efi work with a Microsoft toolchain, which is annoying...
Key input should be consumed to prevent WaitForKey event from being
always triggered and potential buffer overflow.
This fixes issue #26.
Signed-off-by: Kagurazaka Kotori <kagurazakakotori@gmail.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>
