Add sysmacros.h to make gcc happy.

Signed-off-by: Ani Sinha <ani@anisinha.ca>

See upstream commit:
6643507ce30f77500 ("build: Fix GRUB i386-pc build with Ubuntu gcc")

This change is a port of the upstream commit to this version of grub.

With recent versions of gcc on Ubuntu a very large lzma_decompress.img file is
output. (e.g. 134479600 bytes instead of 2864.) This causes grub-mkimage to
fail with: "error: Decompressor is too big."

This seems to be caused by a section .note.gnu.property that is placed at an
offset such that objcopy needs to pad the img file with zeros.

This issue is present on:
Ubuntu 19.10 with gcc (Ubuntu 8.3.0-26ubuntu1~19.10) 8.3.0
Ubuntu 19.10 with gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008

This issue is not present on:
Ubuntu 19.10 with gcc (Ubuntu 7.5.0-3ubuntu1~19.10) 7.5.0
RHEL 8.0 with gcc 8.3.1 20190507 (Red Hat 8.3.1-4)

The issue can be fixed by removing the section using objcopy as shown in
this patch.

Signed-off-by: Ani Sinha <ani@anisinha.ca>
Signed-off-by: Simon Hardy <simon.hardy@itdev.co.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

This is a port of the upstram commit:
842c390469e2c2e10b5 ("x86-64: Treat R_X86_64_PLT32 as R_X86_64_PC32")

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: Ani Sinha <ani@anisinha.ca>
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

This change fixes this gcc warning:

error: 'abort' specifies less restrictive attribute than its target 'grub_abort':
'noreturn' [-Werror=missing-attributes]

It applies 'noreturn' attribute to abort() declaration as well, which has
already been declared as an alias to grub_abort().

Signed-off-by: Ani Sinha <ani@anisinha.ca>

Ignore gcc warning -Wunused-value that causes build failure on newer compiler.

Signed-off-by: Ani Sinha <ani@anisinha.ca>

Disable gcc address-of-packed-member warnings in newer compilers. This warning
results in build failure when enabled since many parts of the grub codebase
access members of the packed structs directly.

Signed-off-by: Ani Sinha <ani@anisinha.ca>

The newer gcc compiler (tried with gcc 9.4) enables PIE/PIC by default. When
compiling 32 bit code, this results in build failure like this:

cat syminfo.lst | sort | awk -f /home/anisinha/workspace/bits/build/grub/grub-core/genmoddep.awk > moddep.lst || (rm -f moddep.lst; exit 1)
_GLOBAL_OFFSET_TABLE_ in python is not defined

The undefined symbol exists in the object file libffi/src/x86/python_module-sysv.o
which is built from the assembly source libffi/src/x86/sysv.S. In this
assembly code, symbol _GLOBAL_OFFSET_TABLE_ is referenced only wnen __PIC__
is defined, which is the default case for the newer compiler.

Fix this by passing -fno-PIC to the CFLAGS for 32 bit compilation case.

Signed-off-by: Ani Sinha <ani@anisinha.ca>

…nteed

ported from upstream commit:
316dda716c046 ("Introduce grub_efi_packed_guid and use it where alignment is not guranteed")

Signed-off-by: Ani Sinha <ani@anisinha.ca>

…inker

a) Fix the linker warning "-r and -pie may not be used together"

The fix has been ported from the Qemu commmit:
c96f0ee6a67ca ("rules.mak: Use -r instead of -Wl, -r to fix building when PIE is default")

With PIE enabled by deafault, we should use "-r" instead of "Wl,-r". The gcc
"-r" option avoids gcc from sending "-pie" to the linker when a relocatable
object is sent as its input.

b) Fix linker warning "PHDR segment not covered by LOAD segment".

To fix this, we send "-static" as the linker argument so that PHDR segment
is not generated.

See also the following note in ld:

Changes in 2.34:

* The ld check for "PHDR segment not covered by LOAD segment" is more
  effective, catching cases that were wrongly allowed by previous versions of
  ld.  If you see this error it is likely you are linking with a bad linker
  script or the binary you are building is not intended to be loaded by a
  dynamic loader.  In the latter case --no-dynamic-linker is appropriate.

Signed-off-by: Ani Sinha <ani@anisinha.ca>

Mem-setting the struct to zero first so that it is properly initialized. It is
to be noted that even without the proper initialization, the code was not
actually accessing uninitialized memory. This change thus does not fix a bug
but only silences a compiler warning.

Signed-off-by: Ani Sinha <ani@anisinha.ca>

This fixes the alignment of some data strructures by making them aligned to
eight byte boundaries. This resolves gcc complaints like the following:

error: alignment 1 of 'struct grub_btrfs_inode' is less than 8 [-Werror=packed-not-aligned]

Signed-off-by: Ani Sinha <ani@anisinha.ca>

This patch addresses implicit fallthrough warnings on the
newer gcc compiler. Proper comment to silence the warning or appropriate comments
have been added in the case statements.

Signed-off-by: Ani Sinha <ani@anisinha.ca>

We bumped into the build error while testing gcc-10 pre-release.

../../grub-core/disk/mdraid1x_linux.c: In function 'grub_mdraid_detect':
../../grub-core/disk/mdraid1x_linux.c:181:15: error: array subscript <unknown> is outside array bounds of 'grub_uint16_t[0]' {aka 'short unsigned int[0]'} [-Werror=array-bounds]
  181 |      (char *) &sb.dev_roles[grub_le_to_cpu32 (sb.dev_number)]
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../grub-core/disk/mdraid1x_linux.c:98:17: note: while referencing 'dev_roles'
   98 |   grub_uint16_t dev_roles[0]; /* Role in array, or 0xffff for a spare, or 0xfffe for faulty.  */
      |                 ^~~~~~~~~
../../grub-core/disk/mdraid1x_linux.c:127:33: note: defined here 'sb'
  127 |       struct grub_raid_super_1x sb;
      |                                 ^~
cc1: all warnings being treated as errors

Apparently gcc issues the warning when trying to access sb.dev_roles
array's member, since it is a zero length array as the last element of
struct grub_raid_super_1x that is allocated sparsely without extra
chunks for the trailing bits, so the warning looks legitimate in this
regard.

As the whole thing here is doing offset computation, it is undue to use
syntax that would imply array member access then take address from it
later. Instead we could accomplish the same thing through basic array
pointer arithmetic to pacify the warning.

Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Definition of GRUB_PACKED was missing. Added it.

Signed-off-by: Ani Sinha <ani@anisinha.ca>

We bumped into the build error while testing gcc-10 pre-release.

In file included from ../../include/grub/file.h:22,
		from ../../grub-core/fs/zfs/zfs.c:34:
../../grub-core/fs/zfs/zfs.c: In function 'zap_leaf_lookup':
../../grub-core/fs/zfs/zfs.c:2263:44: error: array subscript '<unknown>' is outside the bounds of an interior zero-length array 'grub_uint16_t[0]' {aka 'short unsigned int[0]'} [-Werror=zero-length-bounds]
2263 |   for (chunk = grub_zfs_to_cpu16 (l->l_hash[LEAF_HASH (blksft, h, l)], endian);
../../include/grub/types.h:241:48: note: in definition of macro 'grub_le_to_cpu16'
 241 | # define grub_le_to_cpu16(x) ((grub_uint16_t) (x))
     |                                                ^
../../grub-core/fs/zfs/zfs.c:2263:16: note: in expansion of macro 'grub_zfs_to_cpu16'
2263 |   for (chunk = grub_zfs_to_cpu16 (l->l_hash[LEAF_HASH (blksft, h, l)], endian);
     |                ^~~~~~~~~~~~~~~~~
In file included from ../../grub-core/fs/zfs/zfs.c:48:
../../include/grub/zfs/zap_leaf.h:72:16: note: while referencing 'l_hash'
  72 |  grub_uint16_t l_hash[0];
     |                ^~~~~~

Here I'd like to quote from the gcc document [1] which seems best to
explain what is going on here.

"Although the size of a zero-length array is zero, an array member of
this kind may increase the size of the enclosing type as a result of
tail padding. The offset of a zero-length array member from the
beginning of the enclosing structure is the same as the offset of an
array with one or more elements of the same type. The alignment of a
zero-length array is the same as the alignment of its elements.

Declaring zero-length arrays in other contexts, including as interior
members of structure objects or as non-member objects, is discouraged.
Accessing elements of zero-length arrays declared in such contexts is
undefined and may be diagnosed."

The l_hash[0] is apparnetly an interior member to the enclosed structure
while l_entries[0] is the trailing member. And the offending code tries
to access members in l_hash[0] array that triggers the diagnose.

Given that the l_entries[0] is used to get proper alignment to access
leaf chunks, we can accomplish the same thing through the ALIGN_UP macro
thus eliminating l_entries[0] from the structure. In this way we can
pacify the warning as l_hash[0] now becomes the last member to the
enclosed structure.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

…try_type.

…type

Cherry-picked from upstream commit
8b66bb5d8d347a537738 ("* grub-core/fs/zfs/zfscrypt.c (grub_ccm_decrypt):
Return right error type")

Signed-off-by: Ani Sinha <ani@anisinha.ca>

…type. (grub_ehci_fini_hw): Likewise. * grub-core/bus/usb/usbhub.c (grub_usb_add_hub): Likewise.

…usbms_cbi_reset): Likewise. (grub_usbms_bo_reset): Likewise. (grub_usbms_reset): Likewise. (grub_usbms_attach): Likewise. (grub_usbms_transfer_cbi): Likewise.

grub-mkimage is used by grub-mkrescue which in turn is used to generate the
bios bits iso file. We need to ensure that grub-mkimage can run on any host,
even on those that have an earlier version of glibc installed. Hence, we make
it statically linked executable so that the exact version of libraries that are
available on the host where its run does not matter. Thus issues such as the
following can be avoided when executed:

grub-mkimage: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found

Signed-off-by: Ani Sinha <ani@anisinha.ca>