This was the only instance of "library" in core config. A bug was
reported that -fno-stack-protector wasn't passed to it. Instead of
figuring out why it failed just remove this construction used
needlessly.
Add a new timeout_style environment variable and a corresponding
GRUB_TIMEOUT_STYLE configuration key for grub-mkconfig. This
controls hidden-timeout handling more simply than the previous
arrangements, and pressing any hotkeys associated with menu entries
during the hidden timeout will now boot the corresponding menu entry
immediately.
GRUB_HIDDEN_TIMEOUT=<non-empty> + GRUB_TIMEOUT=<non-zero> now
generates a warning, and if it shows the menu it will do so as if
the second timeout were not present. Other combinations are
translated into reasonable equivalents.
A bit tricky because this function has to continue to work without
heap for short strings. Fixing prealloc to 32 arguments is reasonable
but make all stack references use 32-bit offset rather than 8-bit one.
So split va_args preparsing to separate function and put the prealloc
into the caller.
references to mdadm from otherwise generic code.
(grub_util_exec_pipe): Likewise.
(grub_util_exec_pipe_stderr): Likewise.
* grub-core/osdep/unix/getroot.c (grub_util_pull_lvm_by_command):
This function calls vgs, not mdadm; adjust variable names
accordingly.
Add grub_util_disable_fd_syncs call to turn grub_util_fd_sync calls into
no-ops, and use it in programs that copy files but do not need to take
special care to sync writes (grub-mknetdir, grub-rescue,
grub-mkstandalone).
On my laptop, this reduces partmap_test's runtime from 1236 seconds to
204 seconds.
Similar to check for target linking format, also check for efiemu64
instead of hardcoding -melf_x86_64. This fixes compilation on *BSD
variants. We cannot easily reuse main target check because platforms
are different (main target is 32 bit and efiemu64 - 64 bit).
This commit adds EFIEMU64_LINK_FORMAT that contains detected
link option and is used in efiemu64.o linking instead of hardcoded
value.
Reported-By: Beeblebrox <zaphod@berentweb.com>
Previously we misaligned stack by 8 in startup.S and compensated
for it in callwrap.S. According to ABI docs (EFI and sysv amd64)
right behaviour is to align stack in startup.S and keep it aligned
in callwrap.S. startup.S part was committed few commits before. This
takes care of callwrap.S.
Reported by: Gary Lin.
16-byte boundary, as required by the x86-64 ABI, before calling
grub_main. In some cases, GCC emits code that assumes this
alignment, which crashes if not aligned. The EFI firmware is also
entitled to assume that stack alignment without checking.
