In order to avoid using plain integers for the ELF notes use the
available Xen include instead.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Hans van Kranenburg <hans@knorrie.org>
The grub_mkimage_load_image function (commit 7542af6, mkimage: refactor a bunch
of section data into a struct.) introduces a build regression on SPARC:
cc1: warnings being treated as errors
In file included from util/grub-mkimage32.c:23:
util/grub-mkimagexx.c: In function 'grub_mkimage_load_image32':
util/grub-mkimagexx.c:1968: error: missing initializer
util/grub-mkimagexx.c:1968: error: (near initialization for 'smd.sections')
make[2]: *** [util/grub_mkimage-grub-mkimage32.o] Error 1
Initialize the entire section_metadata structure.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Some versions of gcc include a plugin called "annobin", and in some
build systems this is enabled by default. This plugin creates special
ELF note sections to track which ABI-breaking features are used by a
binary, as well as a series of relocations to annotate where.
If grub is compiled with this feature, then when grub-mkimage translates
the binary to another file format which does not strongly associate
relocation data with sections (i.e. when platform is *-efi), these
relocations appear to be against the .text section rather than the
original note section. When the binary is loaded by the PE runtime
loader, hilarity ensues.
This issue is not necessarily limited to the annobin, but could arise
any time there are relocations in sections that are not represented in
grub-mkimage's output.
This patch seeks to avoid this issue by only including relocations that
refer to sections which will be included in the final binary.
As an aside, this should also obviate the need to avoid -funwind-tables,
-fasynchronous-unwind-tables, and any sections similar to .eh_frame in
the future. I've tested it on x86-64-efi with the following gcc command
line options (as recorded by -grecord-gcc-flags), but I still need to
test the result on some other platforms that have been problematic in
the past (especially ARM Aarch64) before I feel comfortable making
changes to the configure.ac bits:
GNU C11 7.2.1 20180116 (Red Hat 7.2.1-7) -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-3dnow -msoft-float -mno-stack-arg-probe -mcmodel=large -mno-red-zone -m64 -mtune=generic -march=x86-64 -g3 -Os -freg-struct-return -fno-stack-protector -ffreestanding -funwind-tables -fasynchronous-unwind-tables -fno-strict-aliasing -fstack-clash-protection -fno-ident -fplugin=annobin
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This basically moves a bunch of the section information we pass around a
lot into a struct, and passes a pointer to a single one of those
instead.
This shouldn't change the binary file output or the "grub-mkimage -v"
output in any way.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This puts both kinds of address initialization at the same place, and also lets
us iterate through the section list one time fewer.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This renames some things:
- the "strtab" and "strtab_section" in relocate_symbols are changed to "symtab"
instead, so as to be less confusing when "strtab" is moved to a struct in a
later patch.
- The places where we pass section_vaddresses to functions are changed to also
be called section_vaddresses"inside those functions, so I get less confused
when I put addresses and vaddresses in a struct in a later patch.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This makes it so you can treat grub-mkimagexx.c as a file you can build
directly, so syntax checkers like vim's "syntastic" plugin, which uses
"gcc -x c -fsyntax-only" to build it, will work.
One still has to do whatever setup is required to make it pick the right
include dirs, which -W options we use, etc., but this makes it so you
can do the checking on the file you're editing, rather than on a
different file.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Starting from binutils commit bd7ab16b4537788ad53521c45469a1bdae84ad4a:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=bd7ab16b4537788ad53521c45469a1bdae84ad4a
x86-64 assembler generates R_X86_64_PLT32, instead of R_X86_64_PC32, for
32-bit PC-relative branches. Grub2 should treat R_X86_64_PLT32 as
R_X86_64_PC32.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
(cherry picked from commit 842c390469)
In util/getroot and efidisk slightly modify exitsing comment to mostly
retain it but still make GCC7 compliant with respect to fall through
annotation.
In grub-core/lib/xzembed/xz_dec_lzma2.c it adds same comments as
upstream.
In grub-core/tests/setjmp_tets.c declare functions as "noreturn" to
suppress GCC7 warning.
In grub-core/gnulib/regexec.c use new __attribute__, because existing
annotation is not recognized by GCC7 parser (which requires that comment
immediately precedes case statement).
Otherwise add FALLTHROUGH comment.
Closes: 50598
According to EABI only STT_FUNC has convention of lowest bit indicating
execution mode. R_THM_{JUMP,CALL}* relocations are assumed to be pointing
to thumb mode unless they use STT_FUNC.
util/grub-mkimagexx.c is included in a special way into mkimage.c.
Interoperation between defines makes this very tricky. Instead
just have a clean interface and compile util/grub-mkimage*.c separately
from mkimage.c
This did not cause real problem but is good for reproducible builds. I hit
it with recent bootinfoscript that displays embedded config; I was puzzled
by random garbage at the end.
Prezero memory buffer used to assemble core.img. This makes individual
memset redundant. Also ensure buffer is filled with zeroes in several other
places.
Also remove redundant zeroing code where we fill in the whole memory block
anyway.
