Re: [PATCH v3] docs: Add debugging chapter to development documentation
Wed, 16 Aug 2023 12:53:48 -0500 Glenn Washburn : > I specifically wanted these two sections to be subsections of > x86_64-efi and not at the same level as i386-pc, hence why I have them > as subsections. I suspect that the issue could be fixed by adding a > @menu in the x86_64-efi section with these two lines. I didn't really > want a menu there, but I'm fine with it if it fixes it for you. Yeah, this is my understanding as well. Now that I have found a way to avoid building the info files, this change is not required from my perspective. Olaf pgpep4YEwCoAU.pgp Description: Digitale Signatur von OpenPGP ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] docs: Add debugging chapter to development documentation
On Wed, 16 Aug 2023 10:41:40 +0200
Olaf Hering wrote:
> Wed, 16 Aug 2023 00:29:28 -0500 Glenn Washburn :
>
> > Anyway, since you're the first and *so far* only person seeing this,
> > could you submit a patch that fixes this for you? It would be great to
> > support older makeinfos (if that is indeed the issue) in the upcoming
> > release.
>
> The change below fixes the following errors:
>
> grub.texi:960: warning: `.' or `,' must follow @xref, not `)'.
> grub.texi:960: warning: for cross-references in parentheses, use @pxref.
> grub-dev.texi:815: `Using the gdbinfo command' has no Up field (perhaps
> incorrect sectioning?).
> grub-dev.texi:791: `OVMF debug log' has no Up field (perhaps incorrect
> sectioning?).
> grub-dev.texi:815: warning: unreferenced node `Using the gdbinfo command'.
>
> With some rewording the first error could be fixed properly.
Thanks for working on this. My comments below.
>
>
> Olaf
>
> --- a/docs/grub-dev.texi
> +++ b/docs/grub-dev.texi
> @@ -632,6 +632,8 @@ various targets using @command{gdb} and the
> @samp{gdb_grub} GDB script.
> @menu
> * i386-pc::
> * x86_64-efi::
> +* OVMF debug log::
> +* Using the gdbinfo command::
I specifically wanted these two sections to be subsections of
x86_64-efi and not at the same level as i386-pc, hence why I have them
as subsections. I suspect that the issue could be fixed by adding a
@menu in the x86_64-efi section with these two lines. I didn't really
want a menu there, but I'm fine with it if it fixes it for you.
> @end menu
>
> @node i386-pc
> @@ -789,7 +791,7 @@ briefly as possible when needed, thus allowing the user
> to have a maximal
> number at their disposal.
>
> @node OVMF debug log
> -@subsection OVMF debug log
> +@section OVMF debug log
>
> In order to get the GRUB2 load address from OVMF, first, a debug build
> of OVMF must be obtained
> (@uref{https://github.com/retrage/edk2-nightly/raw/master/bin/DEBUGX64_OVMF.fd,
> @@ -813,7 +815,7 @@ means that the GRUB2 EFI application was loaded at
> @samp{0x6AEE000} and
> its .text section is at @samp{0x6AEE756}.
>
> @node Using the gdbinfo command
> -@subsection Using the gdbinfo command
> +@section Using the gdbinfo command
>
> On EFI platforms the command @command{gdbinfo} will output a string that
> is to be run in a GDB session running with the @file{gdb_grub} GDB script.
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -957,7 +957,7 @@ information.
>
> GRUB can be run in userspace by invoking the grub2-emu tool. It will
> read all configuration scripts as if booting directly (see @xref{Loading
> -an operating system directly}). With the @code{--kexec} flag, and
> +an operating system directly}.) With the @code{--kexec} flag, and
Actually I think the correction should be:
(@pxref{Loading an operating system directly}).
@xref is for use at the beginning of a sentence and @pxref is for
use inside parenthesis[1].
Glenn
[1]
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Cross-Reference-Commands.html
> kexec(8) support from the operating system, the @command{linux} command
> will directly boot the target image. For systems that lack working
> systemctl(1) support for kexec, passing the @code{--kexec} flag twice
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] docs: Add debugging chapter to development documentation
Wed, 16 Aug 2023 00:29:28 -0500 Glenn Washburn :
> Anyway, since you're the first and *so far* only person seeing this,
> could you submit a patch that fixes this for you? It would be great to
> support older makeinfos (if that is indeed the issue) in the upcoming
> release.
The change below fixes the following errors:
grub.texi:960: warning: `.' or `,' must follow @xref, not `)'.
grub.texi:960: warning: for cross-references in parentheses, use @pxref.
grub-dev.texi:815: `Using the gdbinfo command' has no Up field (perhaps
incorrect sectioning?).
grub-dev.texi:791: `OVMF debug log' has no Up field (perhaps incorrect
sectioning?).
grub-dev.texi:815: warning: unreferenced node `Using the gdbinfo command'.
With some rewording the first error could be fixed properly.
Olaf
--- a/docs/grub-dev.texi
+++ b/docs/grub-dev.texi
@@ -632,6 +632,8 @@ various targets using @command{gdb} and the @samp{gdb_grub}
GDB script.
@menu
* i386-pc::
* x86_64-efi::
+* OVMF debug log::
+* Using the gdbinfo command::
@end menu
@node i386-pc
@@ -789,7 +791,7 @@ briefly as possible when needed, thus allowing the user to
have a maximal
number at their disposal.
@node OVMF debug log
-@subsection OVMF debug log
+@section OVMF debug log
In order to get the GRUB2 load address from OVMF, first, a debug build
of OVMF must be obtained
(@uref{https://github.com/retrage/edk2-nightly/raw/master/bin/DEBUGX64_OVMF.fd,
@@ -813,7 +815,7 @@ means that the GRUB2 EFI application was loaded at
@samp{0x6AEE000} and
its .text section is at @samp{0x6AEE756}.
@node Using the gdbinfo command
-@subsection Using the gdbinfo command
+@section Using the gdbinfo command
On EFI platforms the command @command{gdbinfo} will output a string that
is to be run in a GDB session running with the @file{gdb_grub} GDB script.
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -957,7 +957,7 @@ information.
GRUB can be run in userspace by invoking the grub2-emu tool. It will
read all configuration scripts as if booting directly (see @xref{Loading
-an operating system directly}). With the @code{--kexec} flag, and
+an operating system directly}.) With the @code{--kexec} flag, and
kexec(8) support from the operating system, the @command{linux} command
will directly boot the target image. For systems that lack working
systemctl(1) support for kexec, passing the @code{--kexec} flag twice
pgptpUB69W2lV.pgp
Description: Digitale Signatur von OpenPGP
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] docs: Add debugging chapter to development documentation
On Tue, 15 Aug 2023 22:37:08 +0200 Olaf Hering wrote: > Tue, 15 Aug 2023 12:31:29 -0500 Glenn Washburn : > > > I'm not seeing this issue when building on Debian 11. I'm successfully > > building the info, html, and pdf documentation from the texi files > > using debians texinfo package at version 6.7.0.dfsg.2-6. Are you sure > > you are building from clean sources? What version of texinfo are you at? > > The sources are clean, makeinfo 4.13a is used. Is that a 6+ year old version[1]? Here's my output: $ makeinfo --version texi2any (GNU texinfo) 6.7 Anyway, since you're the first and *so far* only person seeing this, could you submit a patch that fixes this for you? It would be great to support older makeinfos (if that is indeed the issue) in the upcoming release. Glenn [1] https://lists.gnu.org/archive/html/bug-gnulib/2016-06/msg00017.html ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] docs: Add debugging chapter to development documentation
Tue, 15 Aug 2023 12:31:29 -0500 Glenn Washburn : > I'm not seeing this issue when building on Debian 11. I'm successfully > building the info, html, and pdf documentation from the texi files > using debians texinfo package at version 6.7.0.dfsg.2-6. Are you sure > you are building from clean sources? What version of texinfo are you at? The sources are clean, makeinfo 4.13a is used. Olaf pgp7oSGrVuBL3.pgp Description: Digitale Signatur von OpenPGP ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] docs: Add debugging chapter to development documentation
On Tue, 15 Aug 2023 10:14:07 +0200 Olaf Hering wrote: > Thu, 15 Jun 2023 13:06:09 +0200 Daniel Kiper : > > > Right now patch is in the git repo. If you want to improve that part of > > doc please send a fix to grub-devel and CC interested folks. > > Yeah, that is very unfortunate, because it breaks the build: > https://lists.gnu.org/archive/html/bug-grub/2023-06/msg6.html > > 5a3d2b4742dfe4bfe2b51f7b712bc107f75e84ed is the first bad commit > > For some reason there is no --disable-docs for configure? I'm not seeing this issue when building on Debian 11. I'm successfully building the info, html, and pdf documentation from the texi files using debians texinfo package at version 6.7.0.dfsg.2-6. Are you sure you are building from clean sources? What version of texinfo are you at? Glenn ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] docs: Add debugging chapter to development documentation
Thu, 15 Jun 2023 13:06:09 +0200 Daniel Kiper : > Right now patch is in the git repo. If you want to improve that part of > doc please send a fix to grub-devel and CC interested folks. Yeah, that is very unfortunate, because it breaks the build: https://lists.gnu.org/archive/html/bug-grub/2023-06/msg6.html 5a3d2b4742dfe4bfe2b51f7b712bc107f75e84ed is the first bad commit For some reason there is no --disable-docs for configure? Olaf pgp0esDXnERiS.pgp Description: Digitale Signatur von OpenPGP ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] docs: Add debugging chapter to development documentation
On Thu, Jun 15, 2023 at 13:06:09 +0200, Daniel Kiper wrote: > On Thu, Jun 15, 2023 at 01:21:57AM -0500, Oskari Pirhonen wrote: > > Oops, apologies for the late reply. Reading through it again, I found a > > few more small nits: > > Right now patch is in the git repo. If you want to improve that part of > doc please send a fix to grub-devel and CC interested folks. > > Daniel Can do. - Oskari signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] docs: Add debugging chapter to development documentation
On Thu, Jun 15, 2023 at 01:21:57AM -0500, Oskari Pirhonen wrote: > Oops, apologies for the late reply. Reading through it again, I found a > few more small nits: Right now patch is in the git repo. If you want to improve that part of doc please send a fix to grub-devel and CC interested folks. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v3] docs: Add debugging chapter to development documentation
Oops, apologies for the late reply. Reading through it again, I found a
few more small nits:
On Tue, Jun 06, 2023 at 00:48:39 -0500, Glenn Washburn wrote:
> Debugging GRUB can be tricky and require arcane knowledge. This will
> help those unfamiliar with the process to get started debugging GRUB
> with less effort.
>
> Signed-off-by: Glenn Washburn
> ---
> Changes from v1:
> * Add gdbinfo section
> ---
> Interdiff against v2:
> diff --git a/docs/grub-dev.texi b/docs/grub-dev.texi
> index 188ca9c7ca6e..72470b42c61a 100644
> --- a/docs/grub-dev.texi
> +++ b/docs/grub-dev.texi
> @@ -638,7 +638,7 @@ various targets using @command{gdb} and the
> @samp{gdb_grub} GDB script.
>@section i386-pc
>
>The i386-pc target is a good place to start when first debugging GRUB2
> -because in some respects its easier than EFI platforms. The reason being
> +because in some respects it's easier than EFI platforms. The reason being
>that the initial load address is always known in advance. To start
>debugging GRUB2 first QEMU must be started in GDB stub mode. The following
>command is a simple illustration:
> @@ -688,11 +688,11 @@ it does add the module symbols with the appropriate
> offset.
>@section x86_64-efi
>
>Using GDB to debug GRUB2 for the x86_64-efi target has some similarities
> with
> -the i386-pc target. Please read be familiar with the @ref{i386-pc} section
> -when reading this one. Extra care must be used to run QEMU such that it
> boots
> -a UEFI firmware. This usually involves either using the @samp{-bios} option
> -with a UEFI firmware blob (eg. @file{OVMF.fd}) or loading the firmware via
> -pflash. This document will not go further into how to do this as there are
> +the i386-pc target. Please read and familiarize yourself with the
> @ref{i386-pc}
> +section when reading this one. Extra care must be used to run QEMU such
> that it
> +boots a UEFI firmware. This usually involves either using the @samp{-bios}
> +option with a UEFI firmware blob (eg. @file{OVMF.fd}) or loading the
> firmware
> +via pflash. This document will not go further into how to do this as there
> are
>ample resource on the web.
>
>Like all EFI implementations, on x86_64-efi the (U)EFI firmware that loads
> @@ -700,7 +700,7 @@ the GRUB2 EFI application determines at runtime where
> the application will
>be loaded. This means that we do not know where to tell GDB to load the
>symbols for the GRUB2 core until the (U)EFI firmware determines it. There
> are
>two good ways of figuring this out when running in QEMU: use a @ref{OVMF
> debug log,
> -debug build of OVMF} and check the debug log or have GRUB2 say where it is
> +debug build of OVMF} and check the debug log, or have GRUB2 say where it is
>loaded. Neither of these are ideal because they both generally give the
>information after GRUB2 is already running, which makes debugging early
> boot
>infeasible. Technically, the first method does give the load address before
> @@ -734,11 +734,11 @@ application must be run via QEMU at least once prior
> in order to get the
>load address. Two methods for obtaining the load address are described in
>two subsections below. Generally speaking, the load address does not change
>between QEMU runs. There are exceptions to this, namely that different
> -GRUB2 EFI applications can be run at different addresses. Also, its been
> +GRUB2 EFI applications can be run at different addresses. Also, it has been
>observed that after running the EFI application for the first time, the
>second run will some times have a different load address, but subsequent
>runs of the same EFI application will have the same load address as the
> -second run. And its a near certainty that if the GRUB EFI binary has
> changed,
> +second run. And it's a near certainty that if the GRUB EFI binary has
> changed,
>eg. been recompiled, the load address will also be different.
>
>This ability to predict what the load address will be allows one to assume
> @@ -752,7 +752,7 @@ gdb -x gdb_grub -ex 'dynamic_load_symbols @var{address
> of .text section}'
>@end example
>
>If you load the symbols in this manner and, after continuing execution, do
> -not see output showing the loading of modules symbol, then its very likely
> +not see output showing the loading of modules symbol, then it is very
> likely
>that the load address was incorrect.
>
>Another thing to be aware of is how the loading of the GRUB image by the
> @@ -760,8 +760,8 @@ firmware affects previously set software breakpoints.
> On x86 platforms,
>software breakpoints are implemented by GDB by writing a special processor
>instruction at the location of the desired breakpoint. This special
> instruction
>when executed will stop the program execution and hand control to the
> -debugger, GDB. GDB will first saves
Re: [PATCH v3] docs: Add debugging chapter to development documentation
On Tue, Jun 06, 2023 at 12:48:39AM -0500, Glenn Washburn wrote: > Debugging GRUB can be tricky and require arcane knowledge. This will > help those unfamiliar with the process to get started debugging GRUB > with less effort. > > Signed-off-by: Glenn Washburn Reviewed-by: Daniel Kiper Thank you for adding this debugging chapter! Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
