--disable-debug-info enables debug information

[jefftrull]

I am building toolchains for use in Docker containers and I find that the --disable-debug-info configure option does nothing - debug info is always present in the toolchain binaries, causing my container images to be very large. For example:

/configure --disable-gdb --disable-debug-info --with-arch=rv32imc \
--with-abi=ilp32 --with-cmodel=medlow --prefix=`pwd`/installed
make
...
file installed/bin/*

shows all the binaries as with debug_info, not stripped.

I can see that --enable-debug-info does add -g to the compile flags, but it seems like it must be there by default in gcc (at least) and what we need is some way of turning that off.

[TommyMurphyTM1234]

Doesn't --disable-debug-info only apply to the standard library?

• riscv-gnu-toolchain/configure

  Lines 1383 to 1384 in 43536ac

  	--enable-debug-info build glibc/musl/newlibc/libgcc with debug
  	information

Maybe you need to use something like the following?

make ASFLAGS_FOR_TARGET_EXTRA=-g0 CFLAGS_FOR_TARGET_EXTRA=-g0 CXXFLAGS_FOR_TARGET_EXTRA=-g0 ...

E.g. see here:

• Question: why does a make CXXFLAGS_FOR_TARGET_EXTRA=-v build fail? #1530 (comment)

[jefftrull]

That's a great point re: --disable-debug-info. However it does seem as if that too does not work. In the lib directory all the .so files are with debug_info, not stripped. There are some .a files as well and when I extract the .o files from them they also have debug symbols.

Looking at the configure code I think that this switch can only add debug symbols, and it seems that the underlying repos (gcc etc.) already have symbols enabled by default somehow.

I will try your -g0 suggestion.

[TommyMurphyTM1234]

Probably worth looking at the build log to see what flags are being used. It'll be a day or two before I can try a build myself to check this out.

[jefftrull]

Thanks for looking at this. I should be able to make some progress with these tips.

Would you mind clarifying about the extra variables? Judging by the fact that CFLAGS_FOR_TARGET_EXTRA gets combined with -mcmodel=medlow in the Makefile, it seems like it applies to the binaries generated by the toolchain, rather than the toolchain itself (which is at issue in this case). Am I confused? If not, is there a different variable I can use?

[TommyMurphyTM1234]

If you want to affect the toolchain binaries themselves then maybe simply make CFLAGS=-g0 ... or similar? I'm AFK so can't really check at the moment unfortunately.

[jefftrull]

That was the ticket (for the binaries!). Leaving this open for the libraries.

[TommyMurphyTM1234]

That was the ticket (for the binaries!). Leaving this open for the libraries.

Does a combination of configure --disable-debug-info ... and make ASFLAGS_FOR_TARGET_EXTRA=-g0 CFLAGS_FOR_TARGET_EXTRA=-g0 CXXFLAGS_FOR_TARGET_EXTRA=-g0 ... not eliminate debug info for the libraries?

[TommyMurphyTM1234]

FWIW, as far as I can see the riscv-gnu-toolchain top-level Makefile[.in] always uses make install (or equivalent) rather than make install-strip (or equivalent where available) and there is no facility to opt for the stripped install. And, by default, in the absence of configure --disable-debug-info ... and/or make ASFLAGS_FOR_TARGET_EXTRA=-g0 CFLAGS_FOR_TARGET_EXTRA=-g0 CXXFLAGS_FOR_TARGET_EXTRA=-g0 ... and/or make ASFLAGS_FOR_TARGET_EXTRA=-g0 CFLAGS_FOR_TARGET_EXTRA=-g0 CXXFLAGS_FOR_TARGET_EXTRA=-g0 ... etc., everything is built (and installed) with debug information.

I presume that the issue for you @jefftrull is that you want the toolchain to be as lean as possible and not unnecessarily carrying any additional baggage such as debug info/symbols?

Just tagging @ilg-ul to ask if he does something different with his xPack build in order to produce a toolchain distro that bundles some or all components already stripped?

[ilg-ul]

Just tagging @ilg-ul to ask if he does something different with his xPack build in order to produce a toolchain distro that bundles some or all components already stripped?

Can you be more specific? There are a lot of configuration options, both for GCC and binutils.

[TommyMurphyTM1234]

Can you be more specific? There are a lot of configuration options, both for GCC and binutils.

Are some, most or all cross development host and RISC-V target binaries/libraries/object files in the xPack RISC-V GCC toolchain stripped (of debug information/symbols)? I just haven't had a chance to check.

[ilg-ul]

I did not check either, but, as far as I remember, the xPack build scripts strip all native executables and libraries of debug information. There are options to prevent this for development builds.

As for the cross libraries... I don't know, but generally running debug sessions with the GCC runtime and newlib libraries is not possible.

[jefftrull]

That was the ticket (for the binaries!). Leaving this open for the libraries.

Does a combination of configure --disable-debug-info ... and make ASFLAGS_FOR_TARGET_EXTRA=-g0 CFLAGS_FOR_TARGET_EXTRA=-g0 CXXFLAGS_FOR_TARGET_EXTRA=-g0 ... not eliminate debug info for the libraries?

Unfortunately not. libgcc.a, libstdc++.a, and libc.a all contain object files with debug info. I used the following command lines:

./configure --disable-gdb --disable-debug-info --with-arch=rv32imc --with-abi=ilp32 --with-cmodel=medlow --prefix=`pwd`/installed
GCC_EXTRA_CONFIGURE_FLAGS=--enable-target-optspace BINUTILS_TARGET_FLAGS_EXTRA=--enable-target-optspace NEWLIB_TARGET_FLAGS_EXTRA=--enable-target-optspace  CFLAGS=-g0 CXXFLAGS=-g0 ASFLAGS_FOR_TARGET_EXTRA=-g0 CFLAGS_FOR_TARGET_EXTRA=-g0 CXXFLAGS_FOR_TARGET_EXTRA=-g0 gmake -j4

It looks to me as though --disable-debug-info does nothing, because "disabled" is the default state. Some casual Googling has led me to believe that gcc etc. binaries have debug info by default. If I'm right about this, and a good combination of options can be determined, perhaps --disable-debug-info can be made to select them for the user.

[TommyMurphyTM1234]

@jefftrull, what is the problem with debug information in the libraries? In a bare-metal deployment scenario the debug info sections are never actually loaded on the target. They just exist in the ELF file on the development host to facilitate debugging.

What is the exact problem that you are trying to address here?

Other than the fact (it seems) that --[dis|en]able-debug-info may not be working as expected?

[ilg-ul]

The xPack build scripts run lots of post-processing actions, including stripping debug infos.

[jefftrull]

@jefftrull, what is the problem with debug information in the libraries? In a bare-metal deployment scenario the debug info sections are never actually loaded on the target. They just exist in the ELF file on the development host to facilitate debugging.

What is the exact problem that you are trying to address here?

Other than the fact (it seems) that --[dis|en]able-debug-info may not be working as expected?

I am creating Docker container images containing the toolchain, for continuous integration and other purposes. The images produced at the moment are surprisingly large, consuming resources on the host machines as well as taking up time for data transfer. I also discovered that it increases build time (I assume for writing all this data to disk).