[U-Boot-Users] [PATCH 1/6] AVR32: Use -g instead of -gstabs in AFLAGS_DEBUG
In config.mk, -Wa,-gstabs is unconditionally appended to AFLAGS no matter what the target's preferred debugging format is. The AVR32 toolchain doesn't support the stabs debugging format at all, so this will obviously not work.
This patch replaces -gstabs with -g when compiling for AVR32, so that the default debugging format is used. Ulf Samuelsson reported problems on ARM when changing this unconditionally, so this patch has been updated to only change AVR32.
Signed-off-by: Haavard Skinnemoen hskinnemoen@atmel.com --- CHANGELOG: Use -g instead of -gstabs in AFLAGS_DEBUG for AVR32
config.mk | 4 ++++ 1 file changed, 4 insertions(+)
Index: u-boot-1.1.4-git/config.mk =================================================================== --- u-boot-1.1.4-git.orig/config.mk 2006-09-06 15:26:33.000000000 +0200 +++ u-boot-1.1.4-git/config.mk 2006-09-06 15:28:01.000000000 +0200 @@ -164,7 +164,11 @@ CFLAGS := $(CPPFLAGS) -Wall -Wno-trigrap endif endif
+ifeq ($(ARCH),avr32) +AFLAGS_DEBUG := -Wa,-g +else AFLAGS_DEBUG := -Wa,-gstabs +endif
# turn jbsr into jsr for m68k ifeq ($(ARCH),m68k)
In message 20060906162239.3c815063@cad-250-152.norway.atmel.com you wrote:
In config.mk, -Wa,-gstabs is unconditionally appended to AFLAGS no matter what the target's preferred debugging format is. The AVR32 toolchain doesn't support the stabs debugging format at all, so this will obviously not work.
This patch replaces -gstabs with -g when compiling for AVR32, so that the default debugging format is used. Ulf Samuelsson reported problems on ARM when changing this unconditionally, so this patch has been updated to only change AVR32.
Previous identical patch already applied.
Thanks.
Best regards,
Wolfgang Denk
On Tue, 24 Oct 2006 14:59:40 +0200 Wolfgang Denk wd@denx.de wrote:
In message 20060906162239.3c815063@cad-250-152.norway.atmel.com you wrote:
In config.mk, -Wa,-gstabs is unconditionally appended to AFLAGS no matter what the target's preferred debugging format is. The AVR32 toolchain doesn't support the stabs debugging format at all, so this will obviously not work.
This patch replaces -gstabs with -g when compiling for AVR32, so that the default debugging format is used. Ulf Samuelsson reported problems on ARM when changing this unconditionally, so this patch has been updated to only change AVR32.
Previous identical patch already applied.
Not 100% identical...this one only makes a difference on AVR32, while the other one changes everyone to use -g. Ulf reported build problems on ARM with the other patch, so I made it conditional.
Sure you don't want this patch instead of the other one?
Haavard
Hello,
in message 20061024151336.2ab647c6@cad-250-152.norway.atmel.com you wrote:
This patch replaces -gstabs with -g when compiling for AVR32, so that the default debugging format is used. Ulf Samuelsson reported problems on ARM when changing this unconditionally, so this patch has been updated to only change AVR32.
Oops. I missed this.
Previous identical patch already applied.
Not 100% identical...this one only makes a difference on AVR32, while the other one changes everyone to use -g. Ulf reported build problems on ARM with the other patch, so I made it conditional.
Sure you don't want this patch instead of the other one?
I'm not sure. Which sort of problems was this exactly? Whic boards / platforms, and which toolchains?
Best regards,
Wolfgang Denk
On Tue, 24 Oct 2006 16:47:36 +0200 Wolfgang Denk wd@denx.de wrote:
in message 20061024151336.2ab647c6@cad-250-152.norway.atmel.com you wrote:
Not 100% identical...this one only makes a difference on AVR32, while the other one changes everyone to use -g. Ulf reported build problems on ARM with the other patch, so I made it conditional.
Sure you don't want this patch instead of the other one?
I'm not sure. Which sort of problems was this exactly? Whic boards / platforms, and which toolchains?
I'm not sure either, as -g works fine with my ARM toolchain. Ulf, can you elaborate?
Haavard
On Tue, 2006-10-24 at 16:47 +0200, Wolfgang Denk wrote:
Not 100% identical...this one only makes a difference on AVR32, while the other one changes everyone to use -g. Ulf reported build problems on ARM with the other patch, so I made it conditional.
Sure you don't want this patch instead of the other one?
I'm not sure. Which sort of problems was this exactly? Whic boards / platforms, and which toolchains?
Commit 2da2d9a4766063b9848f3a35ad6025499cf87265 is causing build problems when building the latest MPC8540ADS with the follow tools installed:
$ powerpc-unknown-linux-gnu-as
[r56630@cde-tx32-ldt330 u-boot]$ powerpc-unknown-linux-gnu-as -v GNU assembler version 2.15 (powerpc-unknown-linux-gnu) using BFD version 2.15
$ powerpc-unknown-linux-gnu-gcc -v Reading specs from /_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4 --with-local-prefix=/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4 --enable-languages=c,c++,f77 --target=powerpc-unknown-linux-gnu --enable-threads Thread model: posix gcc version 3.4.3
The error is:
powerpc-unknown-linux-gnu-gcc -g -Os -fPIC -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfff80000 -I/temp/u-boot.work/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC85xx -DCONFIG_E500 -ffixed-r2 -ffixed-r29 -Wa,-me500 -msoft-float -mno-string -DCONFIG_MPC85xx=1 -DCONFIG_MPC8540=1 -DCONFIG_E500=1 -Wall -Wstrict-prototypes -c -o sched.o sched.c powerpc-unknown-linux-gnu-gcc -Wa,-g -D__ASSEMBLY__ -g -Os -fPIC -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfff80000 -I/temp/u-boot.work/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC85xx -DCONFIG_E500 -ffixed-r2 -ffixed-r29 -Wa,-me500 -msoft-float -mno-string -DCONFIG_MPC85xx=1 -DCONFIG_MPC8540=1 -DCONFIG_E500=1 -c -o ppc_longjmp.o ppc_longjmp.S /_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/../../../../powerpc-unknown-linux-gnu/bin/as: option `-g' is ambiguous make[1]: *** [ppc_longjmp.o] Error 2 make[1]: Leaving directory `/temp/u-boot.work/u-boot/examples' make: *** [examples] Error 2
I am not immediately sure what is going on but reverting the commit fixes the problem.
-Matthew
On Tue, 24 Oct 2006 19:44:35 -0500 Matthew McClintock msm@freescale.com wrote:
Commit 2da2d9a4766063b9848f3a35ad6025499cf87265 is causing build problems when building the latest MPC8540ADS with the follow tools installed:
$ powerpc-unknown-linux-gnu-as
[r56630@cde-tx32-ldt330 u-boot]$ powerpc-unknown-linux-gnu-as -v GNU assembler version 2.15 (powerpc-unknown-linux-gnu) using BFD version 2.15
Right. The 2.15 documentation doesn't seem to mention the -g option, only -g<debug format>.
Wolfgang, please consider applying the patch below to fix this problem.
---
From: Haavard_Skinnemoen hskinnemoen@atmel.com Subject: [PATCH] Use -g in AFLAGS_DEBUG only on AVR32
Commit 2da2d9a4766063b9848f3a35ad6025499cf87265 changed AFLAGS_DEBUG to use -g instead of -gstabs. It turns out this breaks certain toolchains; at least binutils 2.15 on ppc and 2.16.1 on ARM, as reported by Matthew McClintock and Ulf Samuelsson, respectively.
This is arguably a bug in gas, as the man page for gas 2.16.1 states that the -g option should "generate debugging information for each assembler source line using whichever debug format is preferred by the target."
However, the 2.15 documentation says no such thing, so we should probably stick with using -gstabs for a while longer.
This patch changes config.mk to use -g only when compiling for AVR32 and -gstabs for all other targets.
Signed-off-by: Haavard Skinnemoen hskinnemoen@atmel.com --- config.mk | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/config.mk b/config.mk index 46e956f..6408ade 100644 --- a/config.mk +++ b/config.mk @@ -169,7 +169,11 @@ CFLAGS := $(CPPFLAGS) -Wall -Wno-trigrap endif endif
+ifeq ($(ARCH),avr32) AFLAGS_DEBUG := -Wa,-g +else +AFLAGS_DEBUG := -Wa,-gstabs +endif
# turn jbsr into jsr for m68k ifeq ($(ARCH),m68k)
In message 20061025144151.7039c0e5@cad-250-152.norway.atmel.com you wrote:
Matthew McClintock msm@freescale.com wrote:
Commit 2da2d9a4766063b9848f3a35ad6025499cf87265 is causing build problems when building the latest MPC8540ADS with the follow tools installed:
...
Right. The 2.15 documentation doesn't seem to mention the -g option, only -g<debug format>.
Ummm...
This file is a user guide to the GNU assembler `as' version 2.15.94.0.2.2. ... 1 Overview **********
Here is a brief summary of how to invoke `as'. For details, *note Command-Line Options: Invoking.
as [-a[cdhlns][=FILE]] [-alternate] [-D] [-defsym SYM=VAL] [-f] [-g] [-gstabs] [-gstabs+] [-gdwarf-2] [-help] [-I DIR] [-J] [-K] [-L] ... `-g' `--gen-debug' Generate debugging information for each assembler source line using whichever debug format is preferred by the target. This currently means either STABS, ECOFF or DWARF2.
Am I missing something?
Wolfgang, please consider applying the patch below to fix this problem.
I do, but I'd like to understand the problem first. Matthew's example looked to me as if the gcc driver was calling "as" as a result of a "gcc -g" command, and this should IMHO always work.
Best regards,
Wolfgang Denk
On 10/25/06, Wolfgang Denk wd@denx.de wrote:
In message 20061025144151.7039c0e5@cad-250-152.norway.atmel.com you wrote:
Right. The 2.15 documentation doesn't seem to mention the -g option, only -g<debug format>.
Ummm...
This file is a user guide to the GNU assembler `as' version 2.15.94.0.2.2.
2.15.94 is actually closer to 2.16 than 2.15...
If you look at the as.texinfo file tagged as binutils_2_15, the -g option is only documented for certain targets, e.g. Alpha and MIPS:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/doc/as.texinfo?rev=1.96&...
Wolfgang, please consider applying the patch below to fix this problem.
I do, but I'd like to understand the problem first. Matthew's example looked to me as if the gcc driver was calling "as" as a result of a "gcc -g" command, and this should IMHO always work.
Yes, "gcc -g" should always work. However, in Matthew's example, the command line also included "-Wa,-g", which injects the -g option directly into the command line for the assembler, and that seems to work only for 2.16 and later (or maybe not even that in case of ARM.)
I wonder if gcc will automatically pass the correct -g<whatever> option to gas when it's given the -g option? If that's the case, I suppose we could simply remove -Wa,-g and everyone will be happy...
Haavard
In message 1defaf580610251315l7a3ef385x73628d836daa2238@mail.gmail.com you wrote:
If you look at the as.texinfo file tagged as binutils_2_15, the -g option is only documented for certain targets, e.g. Alpha and MIPS:
I see.
Yes, "gcc -g" should always work. However, in Matthew's example, the command line also included "-Wa,-g", which injects the -g option
"-Wa,-g" is only set in AFLAGS_DEBUG.
directly into the command line for the assembler, and that seems to work only for 2.16 and later (or maybe not even that in case of ARM.)
But we've been using this for a long, long time. It's been working fine with ELDK 3.x (GCC-3.3.3 / binutils 2.14) on ARM, MIPS and PPC.
I wonder if gcc will automatically pass the correct -g<whatever> option to gas when it's given the -g option? If that's the case, I suppose we could simply remove -Wa,-g and everyone will be happy...
I think it does:
-> arm-linux-gcc -v -g -c foo.s Using built-in specs. Target: arm-linux Configured with: /opt/eldk/build/arm-2006-02-19/work/usr/src/denx/BUILD/crosstool-0.35/build/gcc-4.0.0-glibc-2.3.5-eldk/arm-linux/gcc-4.0.0/configure --target=arm-linux --host=i686-host_pc-linux-gnu --prefix=/var/tmp/eldk.Ks4ZhN/usr/crosstool/gcc-4.0.0-glibc-2.3.5-eldk/arm-linux --with-headers=/var/tmp/eldk.Ks4ZhN/usr/crosstool/gcc-4.0.0-glibc-2.3.5-eldk/arm-linux/arm-linux/include --with-local-prefix=/var/tmp/eldk.Ks4ZhN/usr/crosstool/gcc-4.0.0-glibc-2.3.5-eldk/arm-linux/arm-linux --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 4.0.0 (DENX ELDK 4.0 4.0.0) /opt/eldk-4.0-2006-02-19/usr/bin/../lib/gcc/arm-linux/4.0.0/../../../../arm-linux/bin/as --gdwarf2 -mcpu=arm9 -mfpu=softvfp -o foo.o foo.s
See the "--gdwarf2" passed to as.
Best regards,
Wolfgang Denk
On 10/25/06, Wolfgang Denk wd@denx.de wrote:
In message 1defaf580610251315l7a3ef385x73628d836daa2238@mail.gmail.com you wrote:
Yes, "gcc -g" should always work. However, in Matthew's example, the command line also included "-Wa,-g", which injects the -g option
"-Wa,-g" is only set in AFLAGS_DEBUG.
Yes, and it breaks only for assembly files, as shown by Matthew's example:
powerpc-unknown-linux-gnu-gcc -g -Os -fPIC -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfff80000 -I/temp/u-boot.work/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC85xx -DCONFIG_E500 -ffixed-r2 -ffixed-r29 -Wa,-me500 -msoft-float -mno-string -DCONFIG_MPC85xx=1 -DCONFIG_MPC8540=1 -DCONFIG_E500=1 -Wall -Wstrict-prototypes -c -o sched.o sched.c
this one compiles just fine...
powerpc-unknown-linux-gnu-gcc -Wa,-g -D__ASSEMBLY__ -g -Os -fPIC -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfff80000 -I/temp/u-boot.work/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC85xx -DCONFIG_E500 -ffixed-r2 -ffixed-r29 -Wa,-me500 -msoft-float -mno-string -DCONFIG_MPC85xx=1 -DCONFIG_MPC8540=1 -DCONFIG_E500=1 -c -o ppc_longjmp.o ppc_longjmp.S /_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/../../../../powerpc-unknown-linux-gnu/bin/as: option `-g' is ambiguous
...but this one fails because of the -Wa,-g option.
directly into the command line for the assembler, and that seems to work only for 2.16 and later (or maybe not even that in case of ARM.)
But we've been using this for a long, long time. It's been working fine with ELDK 3.x (GCC-3.3.3 / binutils 2.14) on ARM, MIPS and PPC.
Yes, -gstabs has probably been supported a lot longer.
I wonder if gcc will automatically pass the correct -g<whatever> option to gas when it's given the -g option? If that's the case, I suppose we could simply remove -Wa,-g and everyone will be happy...
/opt/eldk-4.0-2006-02-19/usr/bin/../lib/gcc/arm-linux/4.0.0/../../../../arm-linux/bin/as --gdwarf2 -mcpu=arm9 -mfpu=softvfp -o foo.o foo.s
See the "--gdwarf2" passed to as.
Indeed. I can send you a new patch tomorrow which simply removes -Wa,-g for all targets (the -g option should still be there.) Unfortunately, it will be more difficult to spot breakage with such a patch as the assembler will just silently not generate any debug information if you're using a version of gcc which does not pass any -g<whatever> option on to the assembler.
On the other hand, such breakage won't be that critical since things will still build and run properly. I'm not the right person to decide, as there is nothing older than gcc 4.0 and binutils 2.16 available for AVR32. I just need to get rid of the -gstabs option, as the avr32 toolchain only supports dwarf2...
Haavard
On Wed, 25 Oct 2006 23:52:06 +0200 "Haavard Skinnemoen" hskinnemoen@gmail.com wrote:
Indeed. I can send you a new patch tomorrow which simply removes -Wa,-g for all targets (the -g option should still be there.)
Hmmm...it turns out that avr32-gcc does in fact not pass on any --gdwarf2 option to the assembler when using -g. Of course, if this is only true for AVR32, we can fix this, but I'm a bit concerned that this behaviour is arch-specific.
FWIW, here's a patch to remove the -Wa,-g option. If you decide to go for it, I'll make sure the AVR32 toolchain gets fixed.
Haavard
---
From: Haavard Skinnemoen hskinnemoen@atmel.com Subject: [PATCH] Don't pass any debug options directly to the assembler
When passing the -g option to gcc, gcc automatically selects a suitable --g<format> option to pass on to the assembler. Thus, there's no point in forcing a specific debug option on the assembler using the -Wa mechanism.
Signed-off-by: Haavard Skinnemoen hskinnemoen@atmel.com --- config.mk | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/config.mk b/config.mk index 46e956f..f65d3ca 100644 --- a/config.mk +++ b/config.mk @@ -169,7 +169,9 @@ CFLAGS := $(CPPFLAGS) -Wall -Wno-trigrap endif endif
-AFLAGS_DEBUG := -Wa,-g +# $(CPPFLAGS) sets -g, which causes gcc to pass a suitable -g<format> +# option to the assembler. +AFLAGS_DEBUG :=
# turn jbsr into jsr for m68k ifeq ($(ARCH),m68k)
In message 1161737075.5011.8.camel@localhost you wrote:
Commit 2da2d9a4766063b9848f3a35ad6025499cf87265 is causing build problems when building the latest MPC8540ADS with the follow tools installed:
$ powerpc-unknown-linux-gnu-as
How was this configured / built? Ant known to be working standard way like crosstool etc?
The error is:
powerpc-unknown-linux-gnu-gcc -g -Os -fPIC -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfff80000 -I/temp/u-boot.work/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu /i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC85xx -DCONFIG_E500 -ffixed-r2 -ffixed-r29 -Wa,-me500 -msoft-float -mno-string -DCONFIG_MPC85xx=1 -DCONFIG_MPC8540=1 -DCONFIG_E500=1 -W all -Wstrict-prototypes -c -o sched.o sched.c
Ummm... but ${CROSS_COMPILE}gcc -g ... is IMHO a perfectly legal way to run GCC:
`-g' Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging information.
/_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/../../../../powerpc-unknown-linux-gnu/bin/as: option `-g' is ambiguous
I am not immediately sure what is going on but reverting the commit fixes the problem.
IMHO this is a tool configuration issue.
Best regards,
Wolfgang Denk
participants (4)
-
Haavard Skinnemoen -
Haavard Skinnemoen -
Matthew McClintock -
Wolfgang Denk