In several scenarios, configure tests assume it's safe to use
"-Wl,-Ttext,<address>", but starting with ld.lld-21, blindly using that
flag may result in configure-test failures due to ld.lld failing to
link. The failure is because ld.lld-21 no longer allows the specified
address is less than the base address.
However, ld.lld-21+ and ld.bfd-2.44+ both provide support for the
--image-base flag making it preferable over the older -Ttext flag.
Fixes: https://savannah.gnu.org/bugs/?67662
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
or else configure check doesn't succeed with non-bash shell (e.g. dash):
checking whether to enable AMD64 as(1) feature detection... /var/tmp/portage/sys-boot/grub-2.14_rc1/work/grub-2.14~rc1/configure: 39176: test: xx86_64: unexpected operator
no
and later build fails with
/var/tmp/portage/sys-boot/grub-2.14_rc1/work/grub-2.14~rc1/grub-core/lib/libgcrypt-grub/src/hwf-x86.c: In function ‘detect_x86_gnuc’:
/var/tmp/portage/sys-boot/grub-2.14_rc1/work/grub-2.14~rc1/grub-core/lib/libgcrypt-grub/src/hwf-x86.c:252:17: error: ‘HWF_INTEL_CPU’ undeclared (first use in this function)
252 | result |= HWF_INTEL_CPU;
| ^~~~~~~~~~~~~
and other corresponding HWF_INTEL_* definitions because HAVE_CPU_ARCH_X86 was
erroneously not defined by configure script.
Signed-off-by: Lars Wendler <polynomial-c@gmx.de>
Reviewed-by: Gary Lin <glin@suse.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To enable hardware acceleration, this commit ports the feature detection
logic from libgcrypt. This allows us to check if the compiler supports
specific assembly instructions, including SSSE3, Intel SHA extensions,
SSE4.1, AVX, AVX2, AVX512, and BMI2.
To simplify the initial implementation, support for x86_64 feature
detection is currently limited to the x86_64 EFI target.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Some of our paths are too long for tar-v7 at this point but tar-ustar
is supported by essentially everything. So, let's use that.
Signed-off-by: Mate Kukri <mate.kukri@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without this option compiler sometimes emits R_RISCV_ALIGN relocs.
Unlike other relocs this one requires the linker to do NOP deletions
and we can't ignore them. Just instruct compiler not to emit them.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To utilize the key protectors framework, there must be a way to protect
full-disk encryption keys in the first place. The grub-protect tool
includes support for the TPM2 key protector but other protectors that
require setup ahead of time can be supported in the future.
For the TPM2 key protector, the intended flow is for a user to have
a LUKS 1 or LUKS 2-protected fully-encrypted disk. The user then creates
a new LUKS key file, say by reading /dev/urandom into a file, and creates
a new LUKS key slot for this key. Then, the user invokes the grub-protect
tool to seal this key file to a set of PCRs using the system's TPM 2.0.
The resulting sealed key file is stored in an unencrypted partition such
as the EFI System Partition (ESP) so that GRUB may read it. The user also
has to ensure the cryptomount command is included in GRUB's boot script
and that it carries the requisite key protector (-P) parameter.
Sample usage:
$ dd if=/dev/urandom of=luks-key bs=1 count=32
$ sudo cryptsetup luksAddKey /dev/sdb1 luks-key --pbkdf=pbkdf2 --hash=sha512
To seal the key with TPM 2.0 Key File (recommended):
$ sudo grub-protect --action=add \
--protector=tpm2 \
--tpm2-pcrs=0,2,4,7,9 \
--tpm2key \
--tpm2-keyfile=luks-key \
--tpm2-outfile=/boot/efi/efi/grub/sealed.tpm
Or, to seal the key with the raw sealed key:
$ sudo grub-protect --action=add \
--protector=tpm2 \
--tpm2-pcrs=0,2,4,7,9 \
--tpm2-keyfile=luks-key \
--tpm2-outfile=/boot/efi/efi/grub/sealed.key
Then, in the boot script, for TPM 2.0 Key File:
tpm2_key_protector_init --tpm2key=(hd0,gpt1)/efi/grub/sealed.tpm
cryptomount -u <SDB1_UUID> -P tpm2
Or, for the raw sealed key:
tpm2_key_protector_init --keyfile=(hd0,gpt1)/efi/grub/sealed.key --pcrs=0,2,4,7,9
cryptomount -u <SDB1_UUID> -P tpm2
The benefit of using TPM 2.0 Key File is that the PCR set is already
written in the key file, so there is no need to specify PCRs when
invoking tpm2_key_protector_init.
Signed-off-by: Hernan Gatta <hegatta@linux.microsoft.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Without it compiler generates GPREL16 references which do not work
with our memory layout.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Having randomly generated bytes in the binary output breaks reproducible
builds. Since build timestamps are usually the source of irreproducibility
there is a standard which defines an environment variable SOURCE_DATE_EPOCH
to be used when set for build timestamps. According to the standard [1], the
value of SOURCE_DATE_EPOCH is a base-10 integer of the number of seconds
since the UNIX epoch. Currently, this is a 10 digit number that fits into
32-bits, but will not shortly after the year 2100. So to be future-proof
only use the least significant 32-bits. On 64-bit architectures, where the
canary is also 64-bits, there is an extra 32-bits that can be filled to
provide more entropy. The first byte is NUL to filter out string buffer
overflow attacks and the remaining 24-bits are set to static random bytes.
[1] https://reproducible-builds.org/specs/source-date-epoch
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Generating the canary at build time allows the canary to be different for
every build which could limit the effectiveness of certain exploits.
Fallback to the statically generated random bytes if /dev/urandom is not
readable, e.g. Windows.
On 32-bit architectures, which use a 32-bit canary, reduce the canary to
4 bytes with one byte being NUL to filter out string buffer overflow attacks.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
NetBSD uses slightly different function names for the same functions.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without this build-time mkfont fails dynamic linking. This is not ideal
but improves the situation until a better solution is available.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
*BSD puts fonts in other places. Add them to the list.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The HAVE_LIBZFS is defined by libzfs test and hence conflicts with
manual definition. On NetBSD it ends up detecting zfs but not detecting
nvpair and creates confusion. Split them.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Font might be located in different location, the default font might
not be available on all systems or other font might be preferred.
Signed-off-by: Richard Marko <srk@48.io>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Font might be located in different location, the default font might
not be available on all systems or other font might be preferred.
Signed-off-by: Mads Kiilerich <mads@kiilerich.com>
Signed-off-by: Richard Marko <srk@48.io>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the configure phase, the "-mcmodel=large" CFLAGS passed the test, but
because it has not been implemented in gcc, the following warning will
appear when compiling:
gcc: warning: 'large' is not supported, now cmodel is set to 'normal'
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The backtrace module is written assuming that the frame pointer is in %ebp.
By default, -Os optimization level is used, which enables the gcc option
-fomit-frame-pointer. This breaks the backtrace functionality. Enabling
this may cause an unnoticeable performance cost and virtually no size increase.
The backtrace command on x86_64 and probably i386 is broken due to the
above rationale. I've not verified, but presumably the backtrace that used
to be printed for an unhandled CPU exception is also broken. Do any distros
handle this?
Considering that, to my knowledge, no one has complained about this in the
over 13 years that -Os has been used, has this code actually been useful?
Is it worth disabling -fomit-frame-pointer? Though, I don't see much downside
right now in disabling it. Alternatively, we could disable/remove the
backtrace code. I think it would be nice to keep it and have it working.
Nowadays, presumably QEMU makes the GDB stub rarely used as I imagine most
are developing in a virtual machines. Also, the GDB stub does not work in UEFI.
So, if anyone is using it on real hardware, they are doing so on pretty old
machines. The lack of a GDB stub does not seem to be a pain point because
no one has got it working on UEFI.
This patch gets the backtrace command working on x86_64-efi in QEMU for me.
However, it hangs when run on my laptop. Not sure what's going on there.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
During configuration of SDL2, variable enable_grub_emu_sdl2 is checked
whether to throw an error message. However, error could not happen
because two unequal strings were compared. Fix this by referencing
value of enable_grub_emu_sdl2, not name.
Fixes: 17d6ac1a7 (emu: Add SDL2 support)
Signed-off-by: Michał Grzelak <mchl.grzlk@gmail.com>
Reviewed-by: Julian Andres Klode <julian.klode@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
During configuration of SDL, variable enable_grub_emu_sdl is checked
whether to throw an error message. However, error could not happen
because two unequal strings were compared. Fix this by referencing
value of enable_grub_emu_sdl, not name.
Fixes: 17d6ac1a7 (emu: Add SDL2 support)
Signed-off-by: Michał Grzelak <mchl.grzlk@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
So all we did with the surface in SDL1 was split into window,
surface, renderer and texture. Instead of drawing into the
surface and then flipping, you build your pixels, then update
a texture and then copy the texture to the renderer.
Here we use an empty RGB surface to hold our pixels, which enables
us to keep most of the code the same. The SDL1 code has been adjusted
to refer to "surface" instead of "window" when trying to access the
properties of the surface.
This approaches the configuration by adding a new --enable-grub-emu-sdl2
argument. If set to yes, or auto detected, it disables SDL1 support
automatically.
This duplicates the sdl module block in Makefile.core.def which may
be something to be aware of, but we also don't want to build separate
module.
Fixes: https://bugs.debian.org/1038035
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
These should be quite obvious and will make the SDL2 patch easier
to read then doing it inline there.
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A working GRUB cannot be built with upcoming binutils and GCC, because linker
relaxation was added [1] causing new unsupported relocations to appear in modules.
So we pass -mno-relax to GCC if it is supported, to disable relaxation and make
GRUB forward-compatible with new toolchains.
While similar code already exists for sparc64 in configure.ac, sparc64 sets
LDFLAGS while LoongArch requires CFLAGS to be set. If we only set LDFLAGS on
LoongArch, GCC will still generate relaxation relocations in the .o files, so
the sparc64 code cannot be reused.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=56576f4a722b7398d35802ecf7d4185c27d6d69b
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds LoongArch to the GRUB build system and various tools,
so GRUB can be built on LoongArch as a UEFI application.
Signed-off-by: Zhou Yang <zhouyang@loongson.cn>
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A new set of relocation types was added in the LoongArch ELF psABI v2.00
spec [1], [2] to replace the stack-based scheme in v1.00. Toolchain
support is available from binutils 2.40 and gcc 13 onwards.
This patch adds support for the new relocation types, that are simpler
to handle (in particular, stack operations are gone). Support for the
v1.00 relocs are kept for now, for compatibility with older toolchains.
[1] https://github.com/loongson/LoongArch-Documentation/pull/57
[2] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_appendix_revision_history
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When working on memory, it's nice to be able to test your work.
Add a memtest module. When compiled with --enable-mm-debug, it exposes
3 commands:
* lsmem - print all allocations and free space in all regions
* lsfreemem - print free space in all regions
* stress_big_allocs - stress test large allocations:
- how much memory can we allocate in one chunk?
- how many 1MB chunks can we allocate?
- check that gap-filling works with a 1MB aligned 900kB alloc + a
100kB alloc.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Building the current code with clang and the latest gnulib fails due to
the use of a variable-length-array (vla) warning, which turns in to an
error due to the presence of the -Werror during the build.
The gnulib team stated that their code should not be built with -Werror.
At present, the only way to do this is for the complete code-base, by
using the --disable-werror option to configure.
Rather than doing this, and failing to gain any benefit that it provides,
instead, if building with clang, this patch makes it possible to specifically
not error on vlas, while retaining the -Werror functionality otherwise.
Signed-off-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The list of targets that support PCI is in gentpl.py. However, there is no
support for generating makefile script from a .def file that will apply
globally to the makefile, but on a per target basis. So instead, use
gentpl.py in configure to get the list of targets and check if the current
build target is one of them. If it is, set the automake conditional
COND_HAVE_PCI. Then in conf/Makefile.common add -DGRUB_HAS_PCI for the
platform if COND_HAVE_PCI is true.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Introduce ERROR_PLATFORM_NOT_SUPPORT_SSP environment variable to treat
the "--enable-stack-protector is only supported on EFI platforms" message
as a warning instead of an error. If ERROR_PLATFORM_NOT_SUPPORT_SSP is
set to "no" (case-insensitive), then the message will be printed as
a warning. Otherwise, it prints as an error. The default behavior is to
print the message as an error.
For any wrapper build script that has some variation of:
for p in SELECTED_GRUB_PLATFORMS; do \
configure --enable-stack-protector \
--with-platform${P} ... || die; \
done
make
The GRUB will fail to build if SELECTED_GRUB_PLATFORMS contains a platform
that does not support SSP.
Such wrapper scripts need to work-around this issue by modifying the
above for-loop, so it conditionally passes --enable-stack-protector to
configure for the proper GRUB platform(s).
However, if the above example is modified to have to conditionally pass
in --enable-stack-protector, its behavior is effectively the same as the
proposed change. Additionally, The list of SSP supported platforms is
now in 2 places. One in the configure script and one in the build wrapper
script. If the second list is not properly maintained it could mistakenly
disable SSP for a platform that later gained support for it.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Autoconf will set a default CFLAGS of "-g -O2" if CFLAGS is not set.
CFLAGS was defaulted to "" early in configure to prevent this. A recent
commit ad9ccf660 (configure: Fix various new autotools warnings) added
AC_USE_SYSTEM_EXTENSIONS, which pulls in the autoconf CFLAGS check,
before we default CFLAGS and thus setting the autoconf default for
CFLAGS. Move the default setting of CFLAGS to before AC_USE_SYSTEM_EXTENSIONS
so that autoconf will see CFLAGS as set and not give it a default.
CFLAGS is also moved above AC_CONFIG_AUX_DIR, because CFLAGS should be
defaulted to "" as soon as possible to catch any autoconf macros that try
to use some other default. Regardless, this currently has no effect as that
macro does not consider the CFLAGS variable.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
These CFLAGS definitions are reset below them before they have a change to
affect anything. The exception is the *-emu case, which is put in the next
if block, which is the only place its used before getting reset.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It appears as though the intent of this code is to define abort() and main()
symbols for some configure tests. However, it never gets used because the if
is only entered when not building for *-emu, but the next if block only runs
when building for *-emu. And the if block after that unconditionally resets
CFLAGS. So this code can have no effect.
Additionally, s/aclocal.m4/acinclude.m4/ and move grub_ASM_USCORE to put
with other marcos defined in acinclude.m4.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
According to the INSTALL, "The HOST_* variables override not prefixed
variables". This change makes it so, instead of previous behavior, which
was to ignore the HOST_CC environment variable.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In addition to the changes carried in our gnulib patches, several
Coverity and code hygiene fixes that were previously downstream are also
included in this 3-year gnulib increment.
Unfortunately, fix-width.patch is retained.
Bump minimum autoconf version from 2.63 to 2.64 and automake from 1.11
to 1.14, as required by gnulib.
Sync bootstrap script itself with gnulib.
Update regexp module for new dynarray dependency.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
These are probably stray references left after earlier removals.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
The libfuse 3.0.0 got released in 2016, with some API changes compared to 2.x.
This commit introduces support for 3.x while keeping it compatible with 2.6
as a fallback still.
To detect fuse3, switch configure over to use pkg-config, which is simpler yet
more reliable than looking for library and header manually. Also set
FUSE_USE_VERSION that way, as it depends on the used libfuse version.
Now that the CFLAGS are read from pkg-config, use just <fuse.h>, which works
with 2.x as well as 3.x and is recommended by libfuse upstream.
One behavior change of libfuse3 is that FUSE_ATOMIC_O_TRUNC is set by default,
which means that open with O_TRUNC is passed as-is instead of calling the
truncate operation. With libfuse2, truncate failed with -ENOSYS and that was
returned to the application. To make O_TRUNC fail with libfuse3, return -EROFS
explicitly if writing was requested.
Signed-off-by: Fabian Vogt <fvogt@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Define MM_DEBUG in config.h when --enable-mm-debug is passed to configure.
It was being defined in config-util.h which only gets used when building
GRUB utilities for the host side. The enabling of debugging for memory
management in include/grub/mm.h explicitly does not happen when compiling
for the GRUB utilities. So this debugging code effectively could never be
enabled. Note, that MM_DEBUG is defined in an #if directive because the
enabling of debugging checks if MM_DEBUG is defined, not what its value is.
So even if MM_DEBUG were defined to nothing, the debugging code would
still be enabled.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In GNU ld and ld.lld, -d is used with -r to allocate space to COMMON symbols.
This behavior is presumably to work around legacy projects which inspect
relocatable output by themselves and do not handle COMMON symbols. The GRUB
does not do this.
See https://github.com/llvm/llvm-project/issues/53660
-d is quite useless and ld.lld 15.0.0 will make -d no-op.
COMMON symbols have special symbol resolution semantics which can cause surprise
(see https://maskray.me/blog/2022-02-06-all-about-common-symbols). GCC<10 and
Clang<11 defaulted to -fcommon. Just use -fno-common to avoid COMMON symbols.
Signed-off-by: Fangrui Song <maskray@google.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
As of version 2.38 binutils defaults to ISA specification version
2019-12-13. This version of the specification has has separated the
the csr read/write (csrr*/csrw*) instructions and the fence.i from
the I extension and put them into separate Zicsr and Zifencei
extensions.
This implies that we have to adjust the -march flag passed to the
compiler accordingly.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The following procedure to build xen/pvgrub is broken.
git clone https://git.savannah.gnu.org/git/grub.git
cd grub
./bootstrap
mkdir build-xen
cd build-xen
../configure --with-platform=xen
make
It fails with the message:
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
section .note.gnu.property VMA [0000000000400158,0000000000400187]
overlaps section .bss VMA [000000000000f000,000000000041e1af]
The most significant factor is that new assembler (GNU as) generates the
.note.gnu.property section as default. This note section overlaps with
.bss because it doesn't reposition with -Wl,-Ttext,0 with which the base
address of .text section is set, rather the address of .note.gnu.property
is calculated for some reason from 0x400000 where the ELF executable
defaults to start.
Using -Ttext-segment doesn't help either, though it is said to set the
address of the first byte of the text segment according to "man ld".
What it actually does is to override the default 0x400000, aka the image
base address, to something else. The entire process can be observed in
the default linker script used by gcc [1]. Therefore we can't expect it
to achieve the same thing as -Ttext given that the first segment where
.text resides is offset by SIZEOF_HEADERS plus some sections may be
preceding it within the first segment. The end result is .text always
has to start with non-zero address with -Wl,-Ttext-segment,0 if using
default linker script.
It is also worth mentioning that binutils upstream apparently doesn't
seem to consider this as a bug [2] and proposed to use -Wl,-Ttext-segment,0
which is not fruitful as what has been tested by Gentoo [3].
As long as GRUB didn't use ISA information encoded in .note.gnu.property,
we can safely drop it via -Wa,-mx86-used-note=no assembler option to
fix the linker error above.
This is considered a better approach than using custom linker script to
drop the .note.gnu.property section because object file manipulation can
also be hampered one way or the other in that linker script may not be
helpful. See also this commit removing the section in the process of objcopy.
6643507ce build: Fix GRUB i386-pc build with Ubuntu gcc
[1] In /usr/lib64/ldscripts/elf_x86_64.x or use 'gcc -Wl,--verbose ...'
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000));
. = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=27377
[3] https://bugs.gentoo.org/787221
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
