The 32-bit arm Linux kernel is built as a zImage, which self-decompresses
down to near start of RAM. In order for an initrd/initramfs to be
accessible, it needs to be placed within the first ~768MB of RAM.
The initrd loader built into the kernel EFI stub restricts this down to
512MB for simplicity - so enable the same restriction in grub.
For arm64, the requirement is within a 1GB aligned 32GB window also
covering the (runtime) kernel image. Since the EFI stub loader itself
will attempt to relocate to near start of RAM, force initrd to be loaded
completely within the first 32GB of RAM.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The 32-bit arm efi port now shares the 64-bit linux loader, so delete
the now unused bits from the 32-bit linux loader.
This in turn leaves the grub-core/kern/arm/efi/misc.c unused, so
delete that too.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The arm64 and arm linux kernel EFI-stub support presents pretty much
identical interfaces, so the same linux loader source can be used for
both architectures.
Switch 32-bit ARM UEFI platforms over to the existing EFI-stub aware
loader initially developed for arm64.
This *WILL* stop non-efistub Linux kernels from booting on arm-efi.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In preparation for using the linux loader for 32-bit and 64-bit platforms,
rename grub_arm64*/GRUB_ARM64* to grub_armxx*/GRUB_ARMXX*.
Move prototypes for now-common functions to efi/efi.h.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Since ARM platforms do not have a common memory map, add a helper
function that finds the lowest address region with the EFI_MEMORY_WB
attribute set in the UEFI memory map.
Required for the arm64 efi linux loader to restrict the initrd
location to where it will be accessible by the kernel at runtime.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There are several implementations of this function in the tree.
Add a central version in grub-core/efi/mm.c.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI Graphics Output Protocol can return a 64-bit
linear frame buffer address in some firmware/BIOS
implementations. We currently only store the lower
32-bits in the lfb_base. This will eventually be
passed to Linux kernel and the efifb driver will
incorrectly interpret the framebuffer address as
32-bit address.
The Linux kernel has already added support to handle
64-bit linear framebuffer address in the efifb driver
since quite some time now.
This patch adds the support for 64-bit linear frame
buffer address in GRUB to address the above mentioned
scenario.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Clean up code for matching IS_ARM64 slightly by making use of struct
linux_arm64_kernel_header and GRUB_LINUX_ARM64_MAGIC_SIGNATURE.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Clean up code for matching IS_ARM slightly by making use of struct
linux_arm_kernel_header and GRUB_LINUX_ARM_MAGIC_SIGNATURE.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Most 8" or 7" x86 Windows 10 tablets come with volume up/down buttons and
a power-button. In their UEFI these are almost always mapped to arrow
up/down and enter.
Pressing the volume buttons (sometimes by accident) will stop the
menu countdown, but the power-button / "enter" key was not being recognized
as enter, so the user would be stuck at the grub menu.
The problem is that these tablets send scan_code 13 or 0x0d for the
power-button, which officialy maps to the F3 key. They also set
unicode_char to 0x0d.
This commit recognizes the special case of both scan_code and unicode_char
being set to 0x0d and treats this as an enter key press.
This fixes things getting stuck at the grub-menu and allows the user
to choice a grub-menu entry using the buttons on the tablet.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Variable "root" is initialized after root device probing and is null in
current place, so, drop it.
Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without that fix we have:
In file included from ../../include/grub/command.h:25:0,
from ../../grub-core/loader/multiboot.c:30:
../../grub-core/loader/multiboot_elfxx.c: In function 'grub_multiboot_load_elf64':
../../grub-core/loader/multiboot_elfxx.c:130:28: error: 'relocatable' undeclared (first use in this function)
"load_base_addr=0x%x\n", relocatable,
This happens due to mistake in the commit 14ec665
(mbi: Use per segment a separate relocator chunk).
So, let's fix it.
Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
When booting an arm* system on UEFI with an empty device tree (currently
only when hardware description comes from ACPI), we don't currently set
default to 1 cell (32 bits).
Set both of these properties, to 2 cells (64 bits), to resolve issues
with kexec on some platforms.
This change corresponds with linux kernel commit ae8a442dfdc4
("efi/libstub/arm*: Set default address and size cells values for an empty dtb")
and ensures booting through grub does not behave differently from booting
the stub loader directly.
See also https://patchwork.kernel.org/patch/9561201/
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To be able to resuse the prop_entry_size macro, move it to
<grub/fdt.h> and rename it grub_fdt_prop_entry_size.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If something else on the system is using loopback devices, then the
device that's free at the call to `losetup -f` may not be free in the
following call to try to use it. Instead, find and use the first free
loopback device in a single call to losetup.
Signed-off-by: Will Thompson <wjt@endlessm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Instead of setting up a all comprising relocator chunk for all segments,
use per segment a separate relocator chunk.
Currently, if the ELF is non-relocatable, a single relocator chunk will
comprise memory (between the segments) which gets overridden by the relst()
invocation of the movers code in grub_relocator16/32/64_boot().
The overridden memory may contain reserved ranges like VGA memory or ACPI
tables, which may lead to crashes or at least to strange boot behaviour.
Signed-off-by: Alexander Boettcher <alexander.boettcher@genode-labs.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit 51be337 (templates: Update grub script template files)
lacked one "]", so, add it.
Reported-by: Philip <philm@manjaro.org>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
The sparse inode metadata format became a mkfs.xfs default in
xfsprogs-4.16.0, and such filesystems are now rejected by grub as
containing an incompatible feature.
In essence, this feature allows xfs to allocate inodes into fragmented
freespace. (Without this feature, if xfs could not allocate contiguous
space for 64 new inodes, inode creation would fail.)
In practice, the disk format change is restricted to the inode btree,
which as far as I can tell is not used by grub. If all you're doing
today is parsing a directory, reading an inode number, and converting
that inode number to a disk location, then ignoring this feature
should be fine, so I've added it to XFS_SB_FEAT_INCOMPAT_SUPPORTED
I did some brief testing of this patch by hacking up the regression
tests to completely fragment freespace on the test xfs filesystem, and
then write a large-ish number of inodes to consume any existing
contiguous 64-inode chunk. This way any files the grub tests add and
traverse would be in such a fragmented inode allocation. Tests passed,
but I'm not sure how to cleanly integrate that into the test harness.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Chris Murphy <lists@colorremedies.com>
This patch ensures that grub-probe will find the root device placed in
/dev/mapper/dm-[0-9]+-.* e.g. device named /dev/mapper/dm-0-luks will be
found and grub.cfg will be updated properly, enabling the system to boot.
Signed-off-by: Oleg Solovyov <mcpain@altlinux.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rounding up the bufio->block_size to meet power of 2 to facilitate next_buf
calculation in grub_bufio_read().
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Update grub-mkconfig.in and 10_linux.in to support grub-probe's new
partuuid target. Update grub.texi documentation. The following table
shows how GRUB_DISABLE_LINUX_UUID, GRUB_DISABLE_LINUX_PARTUUID, and
initramfs detection interact:
Initramfs GRUB_DISABLE_LINUX_PARTUUID GRUB_DISABLE_LINUX_UUID Linux Root
detected Set Set ID Method
false false false part UUID
false false true part UUID
false true false dev name
false true true dev name
true false false fs UUID
true false true part UUID
true true false fs UUID
true true true dev name
Note: GRUB_DISABLE_LINUX_PARTUUID and GRUB_DISABLE_LINUX_UUID equate to
'false' when unset or set to any value other than 'true'.
GRUB_DISABLE_LINUX_PARTUUID defaults to 'true'.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add PARTUUID detection support grub-probe for MBR and GPT partition schemes.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rename grub_gpt_part_type to grub_gpt_part_guid and update grub_gpt_partentry
to use this type for both the partition type GUID string and the partition GUID
string entries. This change ensures that the two GUID fields are handled more
consistently and helps to simplify the changes needed to add Linux partition
GUID support.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Define print_gpt_guid(), so there is a central function for printing
GUID strings. This change is a precursor for later patches which rely
on this logic.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
With --disable-nls no locales exist.
Avoid runtime error by moving code that copies locales into its own
function. Return early in case nls was disabled. That way the compiler
will throw away unreachable code, no need to put preprocessor
conditionals everywhere to avoid warnings about unused code.
Fix memleak by freeing srcf and dstf.
Convert tabs to spaces in moved code.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
diskboot.img now is loaded at 0x8000 and is jumped to with 0:0x8000.
Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
"F2FS (Flash-Friendly File System) is flash-friendly file system which was merged
into Linux kernel v3.8 in 2013.
The motive for F2FS was to build a file system that from the start, takes into
account the characteristics of NAND flash memory-based storage devices (such as
solid-state disks, eMMC, and SD cards).
F2FS was designed on a basis of a log-structured file system approach, which
remedies some known issues of the older log structured file systems, such as
the snowball effect of wandering trees and high cleaning overhead. In addition,
since a NAND-based storage device shows different characteristics according to
its internal geometry or flash memory management scheme (such as the Flash
Translation Layer or FTL), it supports various parameters not only for
configuring on-disk layout, but also for selecting allocation and cleaning
algorithm.", quote by https://en.wikipedia.org/wiki/F2FS.
The source codes for F2FS are available from:
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.githttp://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git
This patch has been integrated in OpenMandriva Lx 3.
https://www.openmandriva.org/
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When building with GCC 8, there are several errors regarding packed-not-aligned.
./include/grub/gpt_partition.h:79:1: error: alignment 1 of ‘struct grub_gpt_partentry’ is less than 8 [-Werror=packed-not-aligned]
This patch fixes the build error by cleaning up the ambiguity of placing
aligned structure in a packed one. In "struct grub_btrfs_time" and "struct
grub_gpt_part_type", the aligned attribute seems to be superfluous, and also
has to be packed, to ensure the structure is bit-to-bit mapped to the format
laid on disk. I think we could blame to copy and paste error here for the
mistake. In "struct efi_variable", we have to use grub_efi_packed_guid_t, as
the name suggests. :)
Signed-off-by: Michael Chang <mchang@suse.com>
Tested-by: Michael Chang <mchang@suse.com>
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A GPU inserted into a PCIe I/O slot disappears during system startup.
The problem centers around GRUB and a specific VGA init function in
efi_uga.c. This causes an LER (Link Error Recorvery) because the MMIO
memory has not been enabled before attempting access.
The fix is to add the same coding used in other VGA drivers, specifically
to add a check to insure that it is indeed a VGA controller. And then
enable the MMIO address space with the specific bits.
Signed-off-by: Mike Travis <mike.travis@hpe.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Read from NULL pointer canon in function grub_machine_get_bootlocation().
Function grub_ieee1275_canonicalise_devname() may return NULL.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Split up some of the functionality in grub_machine_get_bootlocation into
grub_ieee1275_get_boot_dev. This will allow for code reuse in a follow on
patch.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
These fields must reflect the ROM-BIOS's geometry for CHS-based
loaders to correctly load their next stage. Most loaders do not
query the ROM-BIOS (Int13.08), relying on the BPB fields to hold
the correct values already.
Tested with lDebug booted in qemu via grub2's
FreeDOS direct loading support, refer to
https://bitbucket.org/ecm/ldosboot + https://bitbucket.org/ecm/ldebug
(For this test, lDebug's iniload.asm must be assembled with
-D_QUERY_GEOMETRY=0 to leave the BPB values provided by grub.)
Signed-off-by: C. Masloch <pushbx@38.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add support for multiple, shared, early initrd images. These early
images will be loaded in the order declared, and all will be loaded
before the initrd image.
While many classes of data can be provided by early images, the
immediate use case would be for distributions to provide CPU
microcode to mitigate the Meltdown and Spectre vulnerabilities.
There are two environment variables provided for declaring the early
images.
* GRUB_EARLY_INITRD_LINUX_STOCK is for the distribution declare
images that are provided by the distribution or installed packages.
If undeclared, this will default to a set of common microcode image
names.
* GRUB_EARLY_INITRD_LINUX_CUSTOM is for user created images. User
images will be loaded after the stock images.
These separate configurations allow the distribution and user to
declare different image sets without clobbering each other.
This also makes a minor update to ensure that UUID partition labels
stay disabled when no initrd image is found, even if early images are
present.
This is a continuation of a previous patch published by Christian
Hesse in 2016:
http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00025.html
Down stream Gentoo bug:
https://bugs.gentoo.org/645088
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Matthew S. Turnbull <sparky@bluefang-logic.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
This can cause an issue where GRUB is trying to display both a text and
graphical menu on the display at the same time, resulting in a flickering
effect when e.g. scrolling quickly through a menu (LP: #1752767).
Revert for now while we look for a better solution for the original issue.
This reverts commit 52ef7b23f5.
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Return the 64bit number of blocks of storage associated with the device or
instance. Where a "block" is a unit of storage consisting of the number of
bytes returned by the package's "block-size" method. If the size cannot be
determined, or if the number of blocks exceeds the range return -1.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Return the number of blocks of storage associated with the device or
instance. Where a "block" is a unit of storage consisting of the number
of bytes returned by the package's "block-size" method. If the size cannot
be determined, the #blocks method returns the maximum unsigned integer
(which, because of Open Firmware's assumption of two's complement arithmetic,
is equivalent to the signed number -1). If the number of blocks exceeds
the range of an unsigned number, return 0 to alert the caller to try
the #blocks64 command.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
IEEE Std 1275-1994 Standard for Boot (Initialization Configuration)
Firmware: Core Requirements and Practices
3.8.3 deblocker support package
Any package that uses the "deblocker" support package must define
the following method, which the deblocker uses as a low-level
interface to the device
block-size ( -- block-len ) Return "granularity" for accesses to this
device.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
IEEE 1275-1994 Standard for Boot (Initialization Configuration)
Firmware: Core Requirements and Practices
E.3.2.2 Bus-specific methods for bus nodes
A package implementing the scsi-2 device type shall implement the
following bus-specific method:
no-data-command ( cmd-addr -- error? )
Executes a simple SCSI command, automatically retrying under
certain conditions. cmd-addr is the address of a 6-byte command buffer
containing an SCSI command that does not have a data transfer phase.
Executes the command, retrying indefinitely with the same retry criteria
as retry-command.
error? is nonzero if an error occurred, zero otherwise.
NOTE no-data-command is a convenience function. It provides
no capabilities that are not present in retry-command, but for
those commands that meet its restrictions, it is easier to use.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
IEEE 1275-1994 Standard for Boot (Initialization Configuration)
Firmware: Core Requirements and Practices
E.3.2.2 Bus-specific methods for bus nodes
A package implementing the scsi-2 device type shall implement the
following bus-specific method:
set-address ( unit# target# -- )
Sets the SCSI target number (0x0..0xf) and unit number (0..7) to which
subsequent commands apply.
This function is for devices with #address-cells == 2
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Convert physical address to text unit-string.
Convert phys.lo ... phys-high, the numerical representation, to unit-string,
the text string representation of a physical address within the address
space defined by this device node. The number of cells in the list
phys.lo ... phys.hi is determined by the value of the #address-cells property
of this node.
This function is for devices with #address-cells == 4
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
decode-unit ( addr len -- phys.lo ... phys.hi )
Convert text unit-string to physical address.
Convert unit-string, the text string representation, to phys.lo ... phys.hi,
the numerical representation of a physical address within the address space
defined by this device node. The number of cells in the list
phys.lo ... phys.hi is determined by the value of the #address-cells
property of this node.
This function is for devices with #address-cells == 4
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Limit NVMe of_path_of_nvme to just SPARC hardware for now. It has been
found that non-Open Firmware hardware platforms can some how access
this function.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The of_path_of_nvme function (commit 2391d57, ieee1275: add nvme
support within ofpath) introduced a functional regression:
On systems which are not based on Open Firmware but have at
least one NVME device, find_obppath will return NULL and thus
trying to append the disk name to of_path will result in a
crash.
The proper behavior of of_path_of_nvme is, however, to just
return NULL in such cases, like other users of find_obppath,
such as of_path_of_scsi.
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Reviewed-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This way debuginfo built from the .module will still include this
information, but the final result won't have the data we don't actually
need in the modules, either on-disk, loaded at runtime, or in prebuilt
images.
Signed-off-by: Peter Jones <pjones@redhat.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>
