Re: [MiNT] MiNTLib 0.59.1 Release?

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On Saturday 12 June 2010, Vincent Rivière wrote:
> First, what is -g ? When compiling, this option puts source-level debug
> information into the .o files. Their size increase a lot. This option
> does not affect the code itself, the resulting executable code is exactly
> the same with or wihout -g, the optimization level is not affected.
> When linking with -g, all the source-level debug information is put into
> the final executable. Then it can be debugged with GDB, directly from the
> sources. But the sources must remain at their original place.

I'm not sure about Gdb, but at least with some (Linux) programs you can
tell where the sources pointed by the debug data are.


> Another important fact is that gdb often gets lost with optimized code.
> It is specially true with a.out and STABS debug information (things are
> better with ELF and DWARF debug info).

Even for those it needs a relatively new v4.x GCC version, so that
the debugging data contains location list information (about where
optimized variables are etc).


> For ideal debugging with gdb, the 
> sources have to be compiled without optimization and without
> -fomit-frame-pointer.

What is needed to get working backtraces on GCC/MiNTlib?  Just frame
pointer[1] or also some other things?

I mean, the main thing when debugging is to get working backtraces from
a crash in some C-library function (due e.g. to a bad pointer given to
it[2]) to your own code which is compiled with more debug information.

Working meaning that it can do the unwinding correctly up to your code, not
that it necessarily shows anything about the C-library functions besides
their address and maybe (corrent[3]) name.  Showing libraries function
args needs them to have debug symbols.

[1] Many Linux gcc architectures have also traditionally need this (64-bit
x86, arm...), but recently they've been converting to the new unwind_tables
information generated by gcc.

[2] Good test-case for backtracing is use of a C-library function for which
you give a callback (like qsort()) to your own code which will do e.g.
an abort().  I.e. check that you can get a backtrace for stuff that bounces
between C-lib and your code:
	libc/abort()
	program/callback()
	libc/sort()
	program/test()	// preferably inline to test visiblity of those
	program/main()
	*crt.o/init

[3] Without full debugging information these may be wrong.  Earlier Gdb
versions made guesses, newer Gdb versions show ??? if the name cannot
be "reliably" determined.


> This was the purpose of libc_g.a, which is MUCH 
> bigger than the standard one because of debug information.

I understood from earlier discussion that this "-g" version of libc contains
also something else than just normal _optimized_ libc code + debug symbols
(which can be removed with strip)?   If yes, why?


> Note that there is 2 levels of debug information in the executables:
> - stripped executables or linked with -s: no debug information
> - linked without additional option: assembler symbols only
> - linked with -g: include source-level debug information from .o files
>
> Normally, -g indicates "I want to compile my program with source-level
> debugging because I plan to use gdb on my program". On MiNT, it also
> means "I want to link with the debug version of the MiNTLib to be able to
> trace into it with gdb". The problem is that a lot of standard GNU
> packages link by default with -g to include source-leve debug information
> in any case. If not patched, this kind of packages become unoptimized on
> MiNT...
>
> Really, who is going to trace into the MiNTLib ?

Does the unwinding from C-lib function to your own code work without that?


> As I said, it requires 
> to have the exact sources located at the same location than when
> compiling.

Only if the tool is so bad that you cannot tell it from which directory
it should find the source files...


> This probably applies only to the MiNTLib developers, in some 
> cases, when tracking down a bug. In this case, they probably compile the
> MiNTLib themselves.
>
> So I think we should keep the ability to build a debug MiNTLib in the
> sources, but do not build that mintlib-debug packages as they are useless
> in practice, but certainly error-prone.
>
> And the same strategy should apply to all the libraries. Why a specific
> case for the MiNTLib ?
>
> I'm not familiar with debug libraries in Linux. Since ELF allows
> debugging optimized libraries, and the debug information can be stored in
> external files, things are probably simpler...

By default autotools builds things with debug symbols, this is I guess
a developer conveniences which can normally be overridden with
CFLAGS/CXXFLAGS/LDFLAGS environment variables (but one needs to
check configure.ac for stupid stuff first).

On Linux building binaries for the packages with debug symbols has several
advantages:

* They can at packaging time be split (with objdump) to a separate ELF file
  which contains only the .debug_* ELF sections from the binary, with a CRC
  for the debug symbols added to a .gnu_debuglink section in the stripped
  binary[4]. (Gdb checks the CRC to see that debug symbols really match
  the binary)

* With this, one needs to do only one build to get both optimized & stripped
  binary and the debug symbols which is a large time-save when building
  a lot of packages.

* Besides, unless the debug symbols come from exactly the same build,
  there's a chance that binary gets built slightly differently, which would
  make it useless for debugging core dumps from the non "-g" binary.
  Even worse, you wouldn't know whether they match (Gdb cannot tell)
  and you couldn't trust Gdb information.  (even with matching debug
  symbols, one cannot fully trust what Gdb says...)

*  Having just debug symbols in debug package takes less space and is
    easier to use as Gdb supports them automatically.  Using separate
   debug libraries (which have both code & debug data) needs user to
   specifically tell Gdb to use them, besides them taking more space.


On Saturday 12 June 2010, Vincent Rivière wrote:
> That -g hacking currently applies only to :
> libc.a -> libc_g.a
> crt0.o -> gcrt0.o
>
> If it was logic and consistent, this should apply to all the libraries.
> But it is not the case.
>
> There is also the case of the gprof MiNTLib, named libc_p.a, which is
> similar to the debug one, but used when linking with -p.

Gprof is a separate case because it requires the actual code to be
instrumented and this instrumented code calls the extra functions that
do the counting and sampling while the code runs.

"-g" option shouldn't modify the code or add any extra function calls to
it.


	- Eero