Re: [MiNT] MiNTLib 0.59.1 Release?

[Vincent Rivière <vincent.riviere@freesbee.fr>]

Miro Kropacek wrote:
> What do you say about killing this feature in next release of gcc? (as
> I understand it's mint-specific thing)

We should think to what we need.

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.

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). For ideal debugging with gdb, the sources 
have to be compiled without optimization and without -fomit-frame-pointer. 
This was the purpose of libc_g.a, which is MUCH bigger than the standard one 
because of debug information.

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 ? As I said, it requires to 
have the exact sources located at the same location than when compiling. 
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...

--
Vincent Rivière