[PATCH] ppc: Do not generate .stabs ELF sections to prevent GDB from choking on them
Recent versions of GDB (and probably older ones too, but not checked) crash with and abort when loading the non-stripped 32-bit PPC QEMU build[1]. This is due to a bug in GDB on reading stab symbols. The only place in OpenBIOS where stab symbols are generated is in libgcc/crtsavres.S, which was copied from the linux kernel[2]. Symbols that were defined in the stabs section are still able to be seen in GDB after stabs removal. There does not appear to be a loss in debugging functionality. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28900 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch... Signed-off-by: Glenn Washburn <development@efficientek.com> --- libgcc/crtsavres.S | 4 ---- 1 file changed, 4 deletions(-) diff --git a/libgcc/crtsavres.S b/libgcc/crtsavres.S index 40bd736..8a77ba1 100644 --- a/libgcc/crtsavres.S +++ b/libgcc/crtsavres.S @@ -76,13 +76,9 @@ GLUE(.,name): #define _GLOBAL(n) \ .text; \ - .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n: -/* some stab codes */ -#define N_FUN 36 - #endif /* arch/powerpc/lib/crtsavres.S continues */ -- 2.30.2
On 17/02/2022 19:13, Glenn Washburn wrote:
Recent versions of GDB (and probably older ones too, but not checked) crash with and abort when loading the non-stripped 32-bit PPC QEMU build[1]. This is due to a bug in GDB on reading stab symbols. The only place in OpenBIOS where stab symbols are generated is in libgcc/crtsavres.S, which was copied from the linux kernel[2].
Symbols that were defined in the stabs section are still able to be seen in GDB after stabs removal. There does not appear to be a loss in debugging functionality.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28900 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...
Signed-off-by: Glenn Washburn <development@efficientek.com> --- libgcc/crtsavres.S | 4 ---- 1 file changed, 4 deletions(-)
diff --git a/libgcc/crtsavres.S b/libgcc/crtsavres.S index 40bd736..8a77ba1 100644 --- a/libgcc/crtsavres.S +++ b/libgcc/crtsavres.S @@ -76,13 +76,9 @@ GLUE(.,name):
#define _GLOBAL(n) \ .text; \ - .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n:
-/* some stab codes */ -#define N_FUN 36 - #endif
/* arch/powerpc/lib/crtsavres.S continues */
Thanks for the patch and the related links. From what I can see this looks correct and I see no issues debugging here, so I'll queue this for master pending any further comments (Segher?). ATB, Mark.
On Sat, Feb 19, 2022 at 12:06:50AM +0000, Mark Cave-Ayland wrote:
On 17/02/2022 19:13, Glenn Washburn wrote:
Recent versions of GDB (and probably older ones too, but not checked) crash with and abort when loading the non-stripped 32-bit PPC QEMU build[1]. This is due to a bug in GDB on reading stab symbols. The only place in OpenBIOS where stab symbols are generated is in libgcc/crtsavres.S, which was copied from the linux kernel[2].
Symbols that were defined in the stabs section are still able to be seen in GDB after stabs removal. There does not appear to be a loss in debugging functionality.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28900 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...
Signed-off-by: Glenn Washburn <development@efficientek.com> --- libgcc/crtsavres.S | 4 ---- 1 file changed, 4 deletions(-)
diff --git a/libgcc/crtsavres.S b/libgcc/crtsavres.S index 40bd736..8a77ba1 100644 --- a/libgcc/crtsavres.S +++ b/libgcc/crtsavres.S @@ -76,13 +76,9 @@ GLUE(.,name):
#define _GLOBAL(n) \ .text; \ - .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n:
-/* some stab codes */ -#define N_FUN 36 - #endif
/* arch/powerpc/lib/crtsavres.S continues */
Thanks for the patch and the related links. From what I can see this looks correct and I see no issues debugging here, so I'll queue this for master pending any further comments (Segher?).
The patch is obviously correct. But I have the same question I had with the simlar recent Linux patch: is it useful to have this debug info in Dwarf now, or is it not useful at all? Segher
On 19/02/2022 21:21, Segher Boessenkool wrote:
On Sat, Feb 19, 2022 at 12:06:50AM +0000, Mark Cave-Ayland wrote:
On 17/02/2022 19:13, Glenn Washburn wrote:
Recent versions of GDB (and probably older ones too, but not checked) crash with and abort when loading the non-stripped 32-bit PPC QEMU build[1]. This is due to a bug in GDB on reading stab symbols. The only place in OpenBIOS where stab symbols are generated is in libgcc/crtsavres.S, which was copied from the linux kernel[2].
Symbols that were defined in the stabs section are still able to be seen in GDB after stabs removal. There does not appear to be a loss in debugging functionality.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28900 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...
Signed-off-by: Glenn Washburn <development@efficientek.com> --- libgcc/crtsavres.S | 4 ---- 1 file changed, 4 deletions(-)
diff --git a/libgcc/crtsavres.S b/libgcc/crtsavres.S index 40bd736..8a77ba1 100644 --- a/libgcc/crtsavres.S +++ b/libgcc/crtsavres.S @@ -76,13 +76,9 @@ GLUE(.,name):
#define _GLOBAL(n) \ .text; \ - .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n:
-/* some stab codes */ -#define N_FUN 36 - #endif
/* arch/powerpc/lib/crtsavres.S continues */
Thanks for the patch and the related links. From what I can see this looks correct and I see no issues debugging here, so I'll queue this for master pending any further comments (Segher?).
The patch is obviously correct.
But I have the same question I had with the simlar recent Linux patch: is it useful to have this debug info in Dwarf now, or is it not useful at all?
That is a good question. I'm assuming that since these symbols are still in upstream Linux then they have some utility? I don't think they would be useful on a day-to-day basis unless you were tracking down a compiler bug. ATB, Mark.
Le 20/02/2022 à 18:28, Mark Cave-Ayland a écrit :
On 19/02/2022 21:21, Segher Boessenkool wrote:
On Sat, Feb 19, 2022 at 12:06:50AM +0000, Mark Cave-Ayland wrote:
On 17/02/2022 19:13, Glenn Washburn wrote:
Recent versions of GDB (and probably older ones too, but not checked) crash with and abort when loading the non-stripped 32-bit PPC QEMU build[1]. This is due to a bug in GDB on reading stab symbols. The only place in OpenBIOS where stab symbols are generated is in libgcc/crtsavres.S, which was copied from the linux kernel[2].
Symbols that were defined in the stabs section are still able to be seen in GDB after stabs removal. There does not appear to be a loss in debugging functionality.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28900 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...
Signed-off-by: Glenn Washburn <development@efficientek.com> --- libgcc/crtsavres.S | 4 ---- 1 file changed, 4 deletions(-)
diff --git a/libgcc/crtsavres.S b/libgcc/crtsavres.S index 40bd736..8a77ba1 100644 --- a/libgcc/crtsavres.S +++ b/libgcc/crtsavres.S @@ -76,13 +76,9 @@ GLUE(.,name): #define _GLOBAL(n) \ .text; \ - .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n: -/* some stab codes */ -#define N_FUN 36 - #endif /* arch/powerpc/lib/crtsavres.S continues */
Thanks for the patch and the related links. From what I can see this looks correct and I see no issues debugging here, so I'll queue this for master pending any further comments (Segher?).
The patch is obviously correct.
But I have the same question I had with the simlar recent Linux patch: is it useful to have this debug info in Dwarf now, or is it not useful at all?
That is a good question. I'm assuming that since these symbols are still in upstream Linux then they have some utility? I don't think they would be useful on a day-to-day basis unless you were tracking down a compiler bug.
These symbols are going away in 5.18, see https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=... Christophe
On Sun, Feb 20, 2022 at 05:50:46PM +0000, Christophe Leroy wrote:
Le 20/02/2022 à 18:28, Mark Cave-Ayland a écrit :
On 19/02/2022 21:21, Segher Boessenkool wrote:
On Sat, Feb 19, 2022 at 12:06:50AM +0000, Mark Cave-Ayland wrote:
Thanks for the patch and the related links. From what I can see this looks correct and I see no issues debugging here, so I'll queue this for master pending any further comments (Segher?).
The patch is obviously correct.
But I have the same question I had with the simlar recent Linux patch: is it useful to have this debug info in Dwarf now, or is it not useful at all?
That is a good question. I'm assuming that since these symbols are still in upstream Linux then they have some utility? I don't think they would be useful on a day-to-day basis unless you were tracking down a compiler bug.
These symbols are going away in 5.18, see https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=...
There are no symbols going away. In fact, all debuggers may get enough information from the function symbols themselves, and the STABS info does not add anything. Oh wait, STABS info is encoded in artificial symbol table names, right. The stuff removed from Linux is in the DSO; in OpenBIOS this is in its libgcc code. In GCC itself this code was removed in 2008, and it never has contained STABS info anyway. I have no idea what the OpenBIOS history here is, why the STABS was added in the first place. As far as I can see in the OpenBIOS case the STABS info does not have any value-add. In the Linux case it is not so clear (there is more information encoded there, not just that some function name exists :-) ) So what's the history here? Was this code added to OpenBIOS from some other project? Segher
On 20/02/2022 21:11, Segher Boessenkool wrote:
On Sun, Feb 20, 2022 at 05:50:46PM +0000, Christophe Leroy wrote:
Le 20/02/2022 à 18:28, Mark Cave-Ayland a écrit :
On 19/02/2022 21:21, Segher Boessenkool wrote:
On Sat, Feb 19, 2022 at 12:06:50AM +0000, Mark Cave-Ayland wrote:
Thanks for the patch and the related links. From what I can see this looks correct and I see no issues debugging here, so I'll queue this for master pending any further comments (Segher?).
The patch is obviously correct.
But I have the same question I had with the simlar recent Linux patch: is it useful to have this debug info in Dwarf now, or is it not useful at all?
That is a good question. I'm assuming that since these symbols are still in upstream Linux then they have some utility? I don't think they would be useful on a day-to-day basis unless you were tracking down a compiler bug.
These symbols are going away in 5.18, see https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=...
There are no symbols going away. In fact, all debuggers may get enough information from the function symbols themselves, and the STABS info does not add anything. Oh wait, STABS info is encoded in artificial symbol table names, right.
The stuff removed from Linux is in the DSO; in OpenBIOS this is in its libgcc code. In GCC itself this code was removed in 2008, and it never has contained STABS info anyway. I have no idea what the OpenBIOS history here is, why the STABS was added in the first place.
As far as I can see in the OpenBIOS case the STABS info does not have any value-add. In the Linux case it is not so clear (there is more information encoded there, not just that some function name exists :-) )
So what's the history here? Was this code added to OpenBIOS from some other project?
My guess is that it was taken from historical gcc/Linux since that's where parts of the SPARC code come from. So given that Glenn's patch is echoing what's happening upstream, I'm inclined to take it as-is, and then a separate decision can be taken about the usefulness of the symbols later as they seem to cause no harm. ATB, Mark.
On Mon, Feb 21, 2022 at 08:45:29PM +0000, Mark Cave-Ayland wrote:
On 20/02/2022 21:11, Segher Boessenkool wrote:
There are no symbols going away. In fact, all debuggers may get enough information from the function symbols themselves, and the STABS info does not add anything. Oh wait, STABS info is encoded in artificial symbol table names, right.
The stuff removed from Linux is in the DSO; in OpenBIOS this is in its libgcc code. In GCC itself this code was removed in 2008, and it never has contained STABS info anyway. I have no idea what the OpenBIOS history here is, why the STABS was added in the first place.
As far as I can see in the OpenBIOS case the STABS info does not have any value-add. In the Linux case it is not so clear (there is more information encoded there, not just that some function name exists :-) )
So what's the history here? Was this code added to OpenBIOS from some other project?
My guess is that it was taken from historical gcc/Linux since that's where parts of the SPARC code come from. So given that Glenn's patch is echoing what's happening upstream, I'm inclined to take it as-is, and then a separate decision can be taken about the usefulness of the symbols later as they seem to cause no harm.
The actual code you are removing: #define _GLOBAL(n) \ .text; \ .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n: The STABS means this is an externally visible function called <n>, with return type -1 (which means unspecified afaics), and it has entry point <n> as well. All of this is already made clear to the debugger by the .globl :-) So the patch is fine. But once again, this code is not in Linux, if it ever was there! It seems to be a coincidence that PowerPC Linux is removing its STABS remnants at about this same time :-) Segher
Le 21/02/2022 à 23:25, Segher Boessenkool a écrit :
On Mon, Feb 21, 2022 at 08:45:29PM +0000, Mark Cave-Ayland wrote:
On 20/02/2022 21:11, Segher Boessenkool wrote:
There are no symbols going away. In fact, all debuggers may get enough information from the function symbols themselves, and the STABS info does not add anything. Oh wait, STABS info is encoded in artificial symbol table names, right.
The stuff removed from Linux is in the DSO; in OpenBIOS this is in its libgcc code. In GCC itself this code was removed in 2008, and it never has contained STABS info anyway. I have no idea what the OpenBIOS history here is, why the STABS was added in the first place.
As far as I can see in the OpenBIOS case the STABS info does not have any value-add. In the Linux case it is not so clear (there is more information encoded there, not just that some function name exists :-) )
So what's the history here? Was this code added to OpenBIOS from some other project?
My guess is that it was taken from historical gcc/Linux since that's where parts of the SPARC code come from. So given that Glenn's patch is echoing what's happening upstream, I'm inclined to take it as-is, and then a separate decision can be taken about the usefulness of the symbols later as they seem to cause no harm.
The actual code you are removing:
#define _GLOBAL(n) \ .text; \ .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n:
The STABS means this is an externally visible function called <n>, with return type -1 (which means unspecified afaics), and it has entry point <n> as well.
All of this is already made clear to the debugger by the .globl :-)
So the patch is fine. But once again, this code is not in Linux, if it ever was there! It seems to be a coincidence that PowerPC Linux is removing its STABS remnants at about this same time :-)
Linux kernel's commit 12318163737c ("powerpc/32: Remove remaining .stabs annotations") contains the following hunk: diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h index f21e6bde17a1..c4b074263bf9 100644 --- a/arch/powerpc/include/asm/ppc_asm.h +++ b/arch/powerpc/include/asm/ppc_asm.h @@ -208,7 +208,6 @@ GLUE(.,name): n: #define _GLOBAL(n) \ - .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n: Christophe
On Tue, Feb 22, 2022 at 02:02:36PM +0000, Christophe Leroy wrote:
Le 21/02/2022 à 23:25, Segher Boessenkool a écrit :
The actual code you are removing:
#define _GLOBAL(n) \ .text; \ .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n:
The STABS means this is an externally visible function called <n>, with return type -1 (which means unspecified afaics), and it has entry point <n> as well.
All of this is already made clear to the debugger by the .globl :-)
So the patch is fine. But once again, this code is not in Linux, if it ever was there! It seems to be a coincidence that PowerPC Linux is removing its STABS remnants at about this same time :-)
Linux kernel's commit 12318163737c ("powerpc/32: Remove remaining .stabs annotations") contains the following hunk:
(That isn't in linux.git yet fwiw).
diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h index f21e6bde17a1..c4b074263bf9 100644 --- a/arch/powerpc/include/asm/ppc_asm.h +++ b/arch/powerpc/include/asm/ppc_asm.h @@ -208,7 +208,6 @@ GLUE(.,name): n:
#define _GLOBAL(n) \ - .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n:
Ah! I was looking for {libgcc/,}crtsavres.S and not finding anything :-) Thanks for the clarification. That commit also removes the N_SO entries, which might be more crucial when trying to debug this code, might need some DWARF replacement (to find the source code to this). Segher
Le 22/02/2022 à 17:40, Segher Boessenkool a écrit :
On Tue, Feb 22, 2022 at 02:02:36PM +0000, Christophe Leroy wrote:
Le 21/02/2022 à 23:25, Segher Boessenkool a écrit :
The actual code you are removing:
#define _GLOBAL(n) \ .text; \ .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n:
The STABS means this is an externally visible function called <n>, with return type -1 (which means unspecified afaics), and it has entry point <n> as well.
All of this is already made clear to the debugger by the .globl :-)
So the patch is fine. But once again, this code is not in Linux, if it ever was there! It seems to be a coincidence that PowerPC Linux is removing its STABS remnants at about this same time :-)
Linux kernel's commit 12318163737c ("powerpc/32: Remove remaining .stabs annotations") contains the following hunk:
(That isn't in linux.git yet fwiw).
diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h index f21e6bde17a1..c4b074263bf9 100644 --- a/arch/powerpc/include/asm/ppc_asm.h +++ b/arch/powerpc/include/asm/ppc_asm.h @@ -208,7 +208,6 @@ GLUE(.,name): n:
#define _GLOBAL(n) \ - .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n:
Ah! I was looking for {libgcc/,}crtsavres.S and not finding anything :-) Thanks for the clarification. That commit also removes the N_SO entries, which might be more crucial when trying to debug this code, might need some DWARF replacement (to find the source code to this).
I see that Linux's crtsavres.S (arch/powerpc/lib/crtsavres.S) has the following line: .file "crtsavres.S" Does this needs to be added to all .S files ? Is it enough to have the file name, isn't the path (relative to kernel source base ?) needed as well ? Christophe
On Tue, Feb 22, 2022 at 05:56:34PM +0000, Christophe Leroy wrote:
Ah! I was looking for {libgcc/,}crtsavres.S and not finding anything :-) Thanks for the clarification. That commit also removes the N_SO entries, which might be more crucial when trying to debug this code, might need some DWARF replacement (to find the source code to this).
I see that Linux's crtsavres.S (arch/powerpc/lib/crtsavres.S) has the following line:
(Huh, something failed in my searching apparently!)
.file "crtsavres.S"
Does this needs to be added to all .S files ? Is it enough to have the file name, isn't the path (relative to kernel source base ?) needed as well ?
I do not know. Try it out? When you break on a function in there (or single-step into it, etc.) do you get to see source code (for "list" etc.)? Or does the debugger refuse to break, or complain after breaking, or? Segher
On 17/02/2022 19:13, Glenn Washburn wrote:
Recent versions of GDB (and probably older ones too, but not checked) crash with and abort when loading the non-stripped 32-bit PPC QEMU build[1]. This is due to a bug in GDB on reading stab symbols. The only place in OpenBIOS where stab symbols are generated is in libgcc/crtsavres.S, which was copied from the linux kernel[2].
Symbols that were defined in the stabs section are still able to be seen in GDB after stabs removal. There does not appear to be a loss in debugging functionality.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28900 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...
Signed-off-by: Glenn Washburn <development@efficientek.com> --- libgcc/crtsavres.S | 4 ---- 1 file changed, 4 deletions(-)
diff --git a/libgcc/crtsavres.S b/libgcc/crtsavres.S index 40bd736..8a77ba1 100644 --- a/libgcc/crtsavres.S +++ b/libgcc/crtsavres.S @@ -76,13 +76,9 @@ GLUE(.,name):
#define _GLOBAL(n) \ .text; \ - .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n:
-/* some stab codes */ -#define N_FUN 36 - #endif
/* arch/powerpc/lib/crtsavres.S continues */
Thanks to everyone for their contributions to this thread, I've just pushed this to master. ATB, Mark.
participants (4)
-
Christophe Leroy -
Glenn Washburn -
Mark Cave-Ayland -
Segher Boessenkool