static linking of gdb

static linking of gdb

[Bernd Edlinger]

Hi,

I noticed that gdb is currently not
linking libstdc++ statically, as it did
in the past if I remember correclty.




$ ldd `which gdb`
	linux-vdso.so.1 =>  (0x00007ffe59eb4000)
	libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007f43f4448000)
	libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f43f4218000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f43f4010000)
	libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007f43f3aa8000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f43f3888000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f43f3680000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f43f3378000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f43f3148000)
	libstdc++.so.6 => /home/ed/gnu/install/lib64/libstdc++.so.6 (0x00007f43f4698000)
	libgcc_s.so.1 => /home/ed/gnu/install/lib64/libgcc_s.so.1 (0x00007f43f3128000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f43f2d58000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f43f4670000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f43f2b38000)

this means, this gdb that I build here will not run with the libstdc++ version
that is on my system, by default, only with the gcc version that I used to build.

We should use static libraries as much as possible, especially libstdc++ and libgcc
are not always downward compatible and are easy to make the binary unusable.

$ ldd `which gdbserver`
	linux-vdso.so.1 =>  (0x00007ffea4384000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fac78c08000)
	libstdc++.so.6 => /home/ed/gnu/install/lib64/libstdc++.so.6 (0x00007fac78e38000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fac78900000)
	libgcc_s.so.1 => /home/ed/gnu/install/lib64/libgcc_s.so.1 (0x00007fac788e0000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fac786c0000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fac782f0000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fac78e10000)

even gdbserver is not selfcontained.

compare that to gcc:

$ ldd `which gcc`
	linux-vdso.so.1 =>  (0x00007ffee448c000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffa7da50000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffa7d680000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ffa7dd58000)

which is selfcontained.


All we should do, is at least do add -static-libstdc++ -static-libgcc
to the build rules (when using gcc at least), who knows how to do that,
please do it.


Thanks
Bernd.

Re: static linking of gdb

[Eli Zaretskii]

> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
> Date: Sun, 5 Apr 2020 12:13:42 +0200
> 
> I noticed that gdb is currently not
> linking libstdc++ statically, as it did
> in the past if I remember correclty.

You need to request that by passing --with-static-standard-libraries
to the configure script.  Note that if you do that, you may encounter
an error at configure time, because the configure script thinks the
above option is incompatible with source-highlight library (without
checking whether a static version of that library is available).  This
was reported here:

  https://sourceware.org/pipermail/gdb-patches/2020-February/165843.html

but AFAIK was not fixed yet.

Re: static linking of gdb

[Bernd Edlinger]

Oh, no.

We need to catch exceptions from shared libraries?

Why ?

Not being able to link gdbserver with static libstdc++
will render this tool useless....

Sorry,
Bernd.

On 4/5/20 3:17 PM, Eli Zaretskii wrote:
>> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
>> Date: Sun, 5 Apr 2020 12:13:42 +0200
>>
>> I noticed that gdb is currently not
>> linking libstdc++ statically, as it did
>> in the past if I remember correclty.
> 
> You need to request that by passing --with-static-standard-libraries
> to the configure script.  Note that if you do that, you may encounter
> an error at configure time, because the configure script thinks the
> above option is incompatible with source-highlight library (without
> checking whether a static version of that library is available).  This
> was reported here:
> 
>   https://sourceware.org/pipermail/gdb-patches/2020-February/165843.html
> 
> but AFAIK was not fixed yet.
> 

Re: static linking of gdb

[Bernd Edlinger]

On 4/5/20 3:17 PM, Eli Zaretskii wrote:
>> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
>> Date: Sun, 5 Apr 2020 12:13:42 +0200
>>
>> I noticed that gdb is currently not
>> linking libstdc++ statically, as it did
>> in the past if I remember correclty.
> 
> You need to request that by passing --with-static-standard-libraries
> to the configure script.  Note that if you do that, you may encounter
> an error at configure time, because the configure script thinks the
> above option is incompatible with source-highlight library (without
> checking whether a static version of that library is available).  This
> was reported here:
> 
>   https://sourceware.org/pipermail/gdb-patches/2020-February/165843.html
> 
> but AFAIK was not fixed yet.
> 

Ah, yes, indeed.

I need to configure as
../binutils-gdb/configure --prefix=/home/ed/gnu/gdb-install-1 --disable-binutils --disable-gas --disable-gprof --disable-ld --with-static-standard-libraries --disable-source-highlight

Can someone explain to me why gdbserver needs source highlight?

Or for what I need a source highlight at all ;-) ?

I never used tui mode FWIW.
I do not even use eclipse.


Bernd.

Re: static linking of gdb

[Eli Zaretskii]

> Cc: gdb-patches@sourceware.org, tom@tromey.com
> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
> Date: Sun, 5 Apr 2020 15:48:09 +0200
> 
> Can someone explain to me why gdbserver needs source highlight?

It provides syntax highlighting of the source displayed by GDB.

Re: static linking of gdb

[Bernd Edlinger]

On 4/5/20 4:19 PM, Eli Zaretskii wrote:
>> Cc: gdb-patches@sourceware.org, tom@tromey.com
>> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
>> Date: Sun, 5 Apr 2020 15:48:09 +0200
>>
>> Can someone explain to me why gdbserver needs source highlight?
> 
> It provides syntax highlighting of the source displayed by GDB.
> 

Hmm,

from a pragmatic POV, may I ask, why we do not simply change the
default of

--with-static-standard-libraries --disable-source-highlight

I do not even miss a highlight in gdb and certainly not
in gdbserver, the software is just extremely good as is ;-)

... I just learned recently about backward step, wow ...

I mean the default should just work,
if someone wants some more highlight, then they should just
add --enable-source-highlight
and if that is necessary, do additionally
--without-static-standard-libraries


What do you think?


Bernd.

Re: static linking of gdb

[Bernd Edlinger]

On 4/5/20 3:17 PM, Eli Zaretskii wrote:
>> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
>> Date: Sun, 5 Apr 2020 12:13:42 +0200
>>
>> I noticed that gdb is currently not
>> linking libstdc++ statically, as it did
>> in the past if I remember correclty.
> 
> You need to request that by passing --with-static-standard-libraries
> to the configure script.  Note that if you do that, you may encounter
> an error at configure time, because the configure script thinks the
> above option is incompatible with source-highlight library (without
> checking whether a static version of that library is available).  This
> was reported here:
> 
>   https://sourceware.org/pipermail/gdb-patches/2020-February/165843.html
> 
> but AFAIK was not fixed yet.
> 

But when I follow this pointer,
I end up here:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-08/msg00287.html

> gdb should normally not be linked with -static-libstdc++.  Currently
> this has not caused problems, but it's incompatible with catching an
> exception thrown from a shared library -- and a subsequent patch
> changes gdb to do just this.

Now this makes me a bit nervios.

Tom can you explain where this might happen?
In general I don't think that throwing and catching
exceptions makes a good design, please dont take that personally,
but throwing exceptions of a shared library looks like hazard to me.


Thanks
Bernd.

Re: static linking of gdb

[Bernd Edlinger]

On 4/6/20 5:27 AM, Bernd Edlinger wrote:
> 
> 
> On 4/5/20 3:17 PM, Eli Zaretskii wrote:
>>> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
>>> Date: Sun, 5 Apr 2020 12:13:42 +0200
>>>
>>> I noticed that gdb is currently not
>>> linking libstdc++ statically, as it did
>>> in the past if I remember correclty.
>>
>> You need to request that by passing --with-static-standard-libraries
>> to the configure script.  Note that if you do that, you may encounter
>> an error at configure time, because the configure script thinks the
>> above option is incompatible with source-highlight library (without
>> checking whether a static version of that library is available).  This
>> was reported here:
>>
>>   https://sourceware.org/pipermail/gdb-patches/2020-February/165843.html
>>
>> but AFAIK was not fixed yet.
>>
> 
> But when I follow this pointer,
> I end up here:
> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-08/msg00287.html
> 
>> gdb should normally not be linked with -static-libstdc++.  Currently
>> this has not caused problems, but it's incompatible with catching an
>> exception thrown from a shared library -- and a subsequent patch
>> changes gdb to do just this.
> 
> Now this makes me a bit nervios.
> 
> Tom can you explain where this might happen?
> In general I don't think that throwing and catching
> exceptions makes a good design, please dont take that personally,
> but throwing exceptions of a shared library looks like hazard to me.
> 

Just as an idea,

have you thought of a wrapper.so that does invoke the GNU highlight.so
and catches the exceptions, and converts them to return codes?



Bernd.


> 
> Thanks
> Bernd.
> 

Re: static linking of gdb

[Tom Tromey]

>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:

Bernd> have you thought of a wrapper.so that does invoke the GNU highlight.so
Bernd> and catches the exceptions, and converts them to return codes?

I hadn't considered it.

Tom

Re: static linking of gdb

[Tom Tromey]

>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:

>> gdb should normally not be linked with -static-libstdc++.  Currently
>> this has not caused problems, but it's incompatible with catching an
>> exception thrown from a shared library -- and a subsequent patch
>> changes gdb to do just this.

Bernd> Now this makes me a bit nervios.

Bernd> Tom can you explain where this might happen?

The source highlight library throws exceptions as part of its API.

Tom

Re: static linking of gdb

[Bernd Edlinger]

On 4/6/20 3:42 PM, Tom Tromey wrote:
>>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> 
>>> gdb should normally not be linked with -static-libstdc++.  Currently
>>> this has not caused problems, but it's incompatible with catching an
>>> exception thrown from a shared library -- and a subsequent patch
>>> changes gdb to do just this.
> 
> Bernd> Now this makes me a bit nervios.
> 
> Bernd> Tom can you explain where this might happen?
> 
> The source highlight library throws exceptions as part of its API.
> 

Yes, understood, but why dont you catch them from a shared object,
and return normal return codes, if you like you can throw the same
exception from the static plugin layer ?

> I hadn't considered it.

You definitely should,  it is never too late to correct a wrong decision.
Not being able to link gdb statically is a major usability-regression.


Bernd.

> Tom
> 

Re: static linking of gdb

[Tom Tromey]

>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:

Bernd> You definitely should,  it is never too late to correct a wrong decision.
Bernd> Not being able to link gdb statically is a major usability-regression.

Here:

https://sourceware.org/pipermail/gdb-patches/2020-April/167390.html

... you said you don't want or need source highlight, so I suppose I
considered the matter closed.

Anyway, I don't really understand how your proposal would work.
How does it not just move the problem from gdb to this shim library?

It would be fine to patch source highlight to change the API.
I'm a maintainer of it, I'd approve clean patches to that end.
(However, I don't plan to do it myself, I only became a maintainer to
land a few fixes and do a release.)

Tom