grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: backtrace command broken on x86_64-efi in QEMU


From: Oskari Pirhonen
Subject: Re: backtrace command broken on x86_64-efi in QEMU
Date: Wed, 19 Jul 2023 00:54:19 -0500

On Tue, Jul 18, 2023 at 16:30:44 -0500, Glenn Washburn wrote:
> On Mon, 17 Jul 2023 23:19:23 -0500
> Oskari Pirhonen <xxc3ncoredxx@gmail.com> wrote:
> 
> > On Mon, Jul 17, 2023 at 16:07:09 -0500, Glenn Washburn wrote:
> > > I haven't run this on real hardware, but I would guess it would exhibit
> > > the same behavior. Here's the output I get:
> > > 
> > > grub> insmod backtrace
> > > grub> backtrace
> > > 0x41: 0x0 (0x0,0x0,0x0)
> > > Invalid stack frame at 0x41 (0xc00002)
> > > 
> > 
> > I rebooted into the GRUB console on my machine and ran the same set of
> > commands. It seems to just hang. I left it for about 10 minutes before I
> > force rebooted.
> 
> Thanks for verifying this on real hardware. To be clear, you get no
> output and it just hangs, or you get the output above and then it
> hangs?
> 

Correct, no output.

> It doesn't hang in QEMU (maybe just by chance). I initially thought this
> was partially related to this code not taking stack smashing
> instrumentation into account. But it doesn't look like GCC is
> instrumenting any of those module functions, and I got similar behavior
> when built without stack smashing support. I think the root issue as
> I'm seeing it is that %rbp is being used by GCC as a general register,
> not as the base pointer for a frame, but this code assumes it does.
> 
> I'm guessing that for you grub_backtrace_pointer() was called with a
> NULL argument (%rbp was 0) or something else random that caused a
> read fault which is not handled by GRUB.
> 

That was my hunch as well when I looked at the backtrace.c. Didn't think
about GCC maybe using it for itself, but I did figure it was probably
getting messed up somehow.

> > 
> > Running 2.12~rc1 on x86_64-efi installed through Gentoo.
> 
> Out of curiosity, what configure options is Gentoo building GRUB with?
> 

This is what it seems to be:

/var/tmp/portage/sys-boot/grub-2.12_rc1-r1/work/grub-2.12~rc1/configure
    --prefix=/usr
    --build=x86_64-pc-linux-gnu
    --host=x86_64-pc-linux-gnu
    --mandir=/usr/share/man
    --infodir=/usr/share/info
    --datadir=/usr/share
    --sysconfdir=/etc
    --localstatedir=/var/lib
    --disable-dependency-tracking
    --disable-silent-rules
    --docdir=/usr/share/doc/grub-2.12_rc1-r1
    --htmldir=/usr/share/doc/grub-2.12_rc1-r1/html
    --disable-werror
    --program-prefix=
    --libdir=/usr/lib
    --disable-device-mapper
    --disable-grub-mount
    --enable-nls
    --enable-grub-themes
    --disable-grub-mkfont
    --disable-libzfs
    --disable-grub-emu-sdl
    --with-platform=efi
    --disable-efiemu

Similar for i386-pc (it gets built for both by default). Some of the
options are set based on USE flags.

For some additional reading, you can find the `emerge --info` output for
GRUB [1], the ebuild itself [2], and the build.log (only the configure
stage) [3] linked below.

In the build.log, feel free to ignore any mention of "Connection
refused". That is simply due to the Portage job server not being
accessible because this was done manually and not as part of a normal
package installation.

- Oskari

[1]: https://gist.github.com/xxc3nsoredxx/af58c17e392d4bcbfb2aee6fc501ee3d
[2]: 
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-boot/grub/grub-2.12_rc1-r1.ebuild?id=71cf29063b3a3fb9d7b548d7ed50d62f1e8845a5
[3]: https://gist.github.com/xxc3nsoredxx/db543d21e9c6bdf666bc58ab4215c59c

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]