help: compiling Debian gcc-4.7 with debugging info?

[Basile Starynkevitch]

Hello All (and Alexandre)

To debug a MELT bug (a SIGSEGV in the function dump_edge_info of cc1, called by meltgc_out_edge from melt-runtime.c) I want to compile the exact gc-4.7 package with debugging enabled
-that is with -g flag passed during all the stages of building.

But I really have hard time on that

Alexandre, do you have any clues on how to do that?

Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Alexandre Lissy]

Le 13/12/2012 19:23, Basile Starynkevitch a �crit :

> Hello All (and Alexandre)
>
> To debug a MELT bug (a SIGSEGV in the function dump_edge_info of cc1, called by meltgc_out_edge from melt-runtime.c) I want to compile the exact gc-4.7 package with debugging enabled
> -that is with -g flag passed during all the stages of building.

gcc or melt ?

[Basile Starynkevitch]

On Thu, Dec 13, 2012 at 08:17:45PM +0100, Alexandre Lissy wrote:
> Le 13/12/2012 19:23, Basile Starynkevitch a �crit :
> > Hello All (and Alexandre)
> >
> > To debug a MELT bug (a SIGSEGV in the function dump_edge_info of cc1, called by meltgc_out_edge from melt-runtime.c) I want to compile the exact gc-4.7 package with debugging enabled
> > -that is with -g flag passed during all the stages of building.
>
> gcc or melt ?

When MELT crashes (but that would also help any other GCC plugin developer) I really need to have the debugging information of the cc1 which crashes.

So I really want to have a cc1 which is compiled with -g -O2; it is the cc1 of the distribution.

I am sure any GCC plugin developer also would like that. And basically, as soon as some (free software) program is accepting plugins, it really helps if that program has a debugging variant shipped in the Linux distributions. This is by no mean specific to GCC; I am sure that developpers of gedit plugins also would like to have e.g. a gedit-dbg package containing the debugging information (produced by compiling gedit also with -g -O2) of gedit.

The point is that getting a cc1 with debugging information in Debian (or Mandriva/Maegis) is not simple (at least to me). See my suggestion on http://lists.debian.org/debian-gcc/2012/12/msg00049.html

[Romain Geissler]

Hi

Le 13 déc. 2012 à 21:47, Basile Starynkevitch <bas...@starynkevitch.net> a écrit :
> So I really want to have a cc1 which is compiled with -g -O2; it is the cc1 of the distribution.
>

> The point is that getting a cc1 with debugging information in Debian (or Mandriva/Maegis) is not simple (at least to me). See my suggestion on http://lists.debian.org/debian-gcc/2012/12/msg00049.html

A debug package is indeed a good suggestion. But right know to solve your problem ASAP, why don't you just build gcc with the -g flag?

As explained in http://gcc.gnu.org/install/build.html BOOT_CFLAGS might be what you are looking for, or even better configure gcc with something like:
/path/to/source/configure --with-build-config=bootstrap-debug

Romain

[Basile Starynkevitch]

On Thu, Dec 13, 2012 at 10:13:47PM +0100, Romain Geissler wrote:
> Hi
>
> Le 13 d�c. 2012 � 21:47, Basile Starynkevitch <bas...@starynkevitch.net> a �crit :

> > So I really want to have a cc1 which is compiled with -g -O2; it is the cc1 of the distribution.
> >
> > The point is that getting a cc1 with debugging information in Debian (or Mandriva/Maegis) is not simple (at least to me). See my suggestion on http://lists.debian.org/debian-gcc/2012/12/msg00049.html
>
> A debug package is indeed a good suggestion. But right know to solve your problem ASAP, why don't you just build gcc with the -g flag?

Actually, I found the bug on my MELT branch which is built with CFLAGS='-O -g'

But really, I believe that for all GCC plugin developers, having a debug variant of gcc (& cc1 & cc1plus ....) should be helpful. This is not specific to MELT.

Requiring GCC plugin developers to compile the GCC compiler themselves is
IMHO sort-of defeating the plugin idea....


(Actually, I tend to believe that any free software which has plugins -i.e. which use dlopen against external shared objects- should be packaged in debug variants. It is not only libraries which should have -as they already do on Debian- a debug variant, it is every software accepting plugins).


Cheers.

[Romain Geissler]

Le 13 déc. 2012 à 22:32, Basile Starynkevitch <bas...@starynkevitch.net> a écrit :

> On Thu, Dec 13, 2012 at 10:13:47PM +0100, Romain Geissler wrote:
>> Hi
>>

>> Le 13 déc. 2012 à 21:47, Basile Starynkevitch <bas...@starynkevitch.net> a écrit :
>>> So I really want to have a cc1 which is compiled with -g -O2; it is the cc1 of the distribution.
>>>
>>> The point is that getting a cc1 with debugging information in Debian (or Mandriva/Maegis) is not simple (at least to me). See my suggestion on http://lists.debian.org/debian-gcc/2012/12/msg00049.html
>>
>> A debug package is indeed a good suggestion. But right know to solve your problem ASAP, why don't you just build gcc with the -g flag?
>
>
> Actually, I found the bug on my MELT branch which is built with CFLAGS='-O -g'
>
> But really, I believe that for all GCC plugin developers, having a debug variant of gcc (& cc1 & cc1plus ....) should be helpful. This is not specific to MELT.

Yeah sure, and i don't know why package delivered in Linux distros like Debian don't always come with there -dbg counter part (ie stripped elf binaries containing all DWARF debug information, that GDB is able to combine to the regular binary).

> Requiring GCC plugin developers to compile the GCC compiler themselves is

> IMHO sort-of defeating the plugin idea….

In the very particular case of GCC, i think that compiling it by yourself is inevitable, at least it was at the time i used it.

> (Actually, I tend to believe that any free software which has plugins -i.e. which use dlopen against external shared objects- should be packaged in debug variants. It is not only libraries which should have -as they already do on Debian- a debug variant, it is every software accepting plugins).

Softwares that aren't plugin-aware deserve debug symbols as much as softwares that loads plugins: you'ill be glad to have them when your process core dump'ed even if it didn't dlopen some file. You can also remove the "free" part of your assertion, i investigate core dumps generated by proprietary software every days, and believe me, debug symbols are welcomed too in proprietary binaries. It's simple, any ELF-distributed software should come with both --strip-debug and --keep-only-debug ELF files, with a --build-id to uniquely identify a given binary and help GDB to find the right corresponding debug symbol ELF file.

R