static musl-based gdb and -fPIC

static musl-based gdb and -fPIC

[writeonce]

Greetings,

While building a statically linked musl-based gdb, ld asked that libc.a 
be recompiled with -fPIC.  After recompiling musl with the above flag, 
gdb built successfully.  The reason I wanted to have a static gdb (other 
than the trivial ones) was to be able to debug a musl-based python.  The 
distribution's gdb has a dynamic dependency on a glibc-based libpython, 
and the two friends don't play well together.

Now that the static gdb is up and running, my questions are:

1) is there any reason not to "always" compile musl with -fPIC, at least 
on x86_64?

2) is there any reason to revert to the old build of libc.so? Although I 
rebuilt musl because of libc.a, it turns out that the -fPIC flag also 
helped libc.so become much smaller: 699299 bytes, instead of 2767910 
bytes (musl v1.0.0, binutils v2.24).  Any other factors to consider?

Thanks for looking at this,
zg

Re: static musl-based gdb and -fPIC

[writeonce]

On 04/20/2014 01:03 PM, writeonce@midipix.org wrote:
> Greetings,
>
> While building a statically linked musl-based gdb, ld asked that 
> libc.a be recompiled with -fPIC.  After recompiling musl with the 
> above flag, gdb built successfully.  The reason I wanted to have a 
> static gdb (other than the trivial ones) was to be able to debug a 
> musl-based python.  The distribution's gdb has a dynamic dependency on 
> a glibc-based libpython, and the two friends don't play well together.
>
> Now that the static gdb is up and running, my questions are:
>
> 1) is there any reason not to "always" compile musl with -fPIC, at 
> least on x86_64?
>
> 2) is there any reason to revert to the old build of libc.so? Although 
> I rebuilt musl because of libc.a, it turns out that the -fPIC flag 
> also helped libc.so become much smaller: 699299 bytes, instead of 
> 2767910 bytes (musl v1.0.0, binutils v2.24).  Any other factors to 
> consider?

Pardon!  Of the two files above, only the larger one had debug 
information.   With -fPIC and debug information, the current size of 
libc.so is 2379780 bytes.

>
> Thanks for looking at this,
> zg
>
>
>

Re: static musl-based gdb and -fPIC

[Rich Felker]

On Sun, Apr 20, 2014 at 01:03:12PM -0400, writeonce@midipix.org wrote:
> Greetings,
> 
> While building a statically linked musl-based gdb, ld asked that
> libc.a be recompiled with -fPIC.

This is a bug in the gdb build process. Despite your request for a
static gdb, it's trying to build a shared library for something.
There's a way to disable it (IIRC --disable-gdbserver is a big hammer
that can do it, and there might be a more fine-grained approach) but
the real issue is that the build process is broken and doing something
that can't work.

> After recompiling musl with the
> above flag, gdb built successfully.  The reason I wanted to have a
> static gdb (other than the trivial ones) was to be able to debug a
> musl-based python.  The distribution's gdb has a dynamic dependency
> on a glibc-based libpython, and the two friends don't play well
> together.
> 
> Now that the static gdb is up and running, my questions are:
> 
> 1) is there any reason not to "always" compile musl with -fPIC, at
> least on x86_64?

Compare the .lo and .o files. I think you'll find the .lo files are a
considerably more bloated and slower -- not as bad as on 32-bit x86,
but still undesirable.

Some users will want to use -fPIC even for static linking to be able
to produce static PIE binaries, but this is not a mainstream usage
(there's not even any official toolchain support for it, just a local
hack I posted to the list a year or two back) and not something we
would want to impose on everyone.

> 2) is there any reason to revert to the old build of libc.so?
> Although I rebuilt musl because of libc.a, it turns out that the
> -fPIC flag also helped libc.so become much smaller: 699299 bytes,
> instead of 2767910 bytes (musl v1.0.0, binutils v2.24).  Any other
> factors to consider?

You must have done something else like disabling debugging info at the
same time.

Rich

Re: static musl-based gdb and -fPIC

[writeonce]

On 04/20/2014 04:31 PM, Rich Felker wrote:
> On Sun, Apr 20, 2014 at 01:03:12PM -0400, writeonce@midipix.org wrote:
>> Greetings,
>>
>> While building a statically linked musl-based gdb, ld asked that
>> libc.a be recompiled with -fPIC.
> This is a bug in the gdb build process. Despite your request for a
> static gdb, it's trying to build a shared library for something.
> There's a way to disable it (IIRC --disable-gdbserver is a big hammer
> that can do it, and there might be a more fine-grained approach) but
> the real issue is that the build process is broken and doing something
> that can't work.

Thanks!  The offending part was indeed in gdbserver.  With 
--disable-gdbserver, -fPIC is no longer necessary.  Looking into this, I 
thought the problem lied in gdb/gdbserver/Makefile.in

     LDFLAGS = @LDFLAGS@
     INTERNAL_LDFLAGS = $(LDFLAGS) @RDYNAMIC@

however removing @RDYNAMIC@ did not solve the issue, so for the time 
being gdbserver will have to be disabled.

For the record: python's Modules/posixmodule.c has a static 
implementation of posix_close that is incompatible with musl's.  My 
first take on that was to make python use musl's posix_close, which 
resulted in a very subtle bug leading to a segmentation fault (not to 
mention all of those lost hours...)  Renaming the module's posix_close 
to __posix_close solved the problem.  The code that triggered the bug was

     import subprocess
     subprocess.Popen(['ls'])

With the newer approach (__posix_close) everything seems to work fine.

Thanks again,
zg


>
>> After recompiling musl with the
>> above flag, gdb built successfully.  The reason I wanted to have a
>> static gdb (other than the trivial ones) was to be able to debug a
>> musl-based python.  The distribution's gdb has a dynamic dependency
>> on a glibc-based libpython, and the two friends don't play well
>> together.
>>
>> Now that the static gdb is up and running, my questions are:
>>
>> 1) is there any reason not to "always" compile musl with -fPIC, at
>> least on x86_64?
> Compare the .lo and .o files. I think you'll find the .lo files are a
> considerably more bloated and slower -- not as bad as on 32-bit x86,
> but still undesirable.
>
> Some users will want to use -fPIC even for static linking to be able
> to produce static PIE binaries, but this is not a mainstream usage
> (there's not even any official toolchain support for it, just a local
> hack I posted to the list a year or two back) and not something we
> would want to impose on everyone.
>
>> 2) is there any reason to revert to the old build of libc.so?
>> Although I rebuilt musl because of libc.a, it turns out that the
>> -fPIC flag also helped libc.so become much smaller: 699299 bytes,
>> instead of 2767910 bytes (musl v1.0.0, binutils v2.24).  Any other
>> factors to consider?
> You must have done something else like disabling debugging info at the
> same time.
>
> Rich
>
>

Re: static musl-based gdb and -fPIC

[Szabolcs Nagy]

* writeonce@midipix.org <writeonce@midipix.org> [2014-04-20 17:39:37 -0400]:
> For the record: python's Modules/posixmodule.c has a static
> implementation of posix_close that is incompatible with musl's.  My

yes they define posix_ prefixed symbols for internal use
which are reserved names for the c implementation when
any standard headers are included

the next posix standard defines posix_close so this is a
real collision (and will be an issue with every conformant
libc), but all the other posix_ symbols are wrong there too

> first take on that was to make python use musl's posix_close, which
> resulted in a very subtle bug leading to a segmentation fault (not
> to mention all of those lost hours...)  Renaming the module's
> posix_close to __posix_close solved the problem.  The code that

these functions have nothing to do with libc: they operate on
python objects

the symbols should be just renamed but your solution is wrong:
the __ prefix is still in the reserved name space

use s/posix_/pyposix_/ or similar

Re: static musl-based gdb and -fPIC

[Szabolcs Nagy]

* Szabolcs Nagy <nsz@port70.net> [2014-04-21 09:33:47 +0200]:
> yes they define posix_ prefixed symbols for internal use
> which are reserved names for the c implementation when
> any standard headers are included
> 
> the next posix standard defines posix_close so this is a
> real collision (and will be an issue with every conformant
> libc), but all the other posix_ symbols are wrong there too

it seems it was already reported and "fixed"
http://bugs.python.org/issue20594

the fix is broken though

Re: static musl-based gdb and -fPIC

[writeonce]

On 04/21/2014 03:33 AM, Szabolcs Nagy wrote:
> * writeonce@midipix.org <writeonce@midipix.org> [2014-04-20 17:39:37 -0400]:
>> For the record: python's Modules/posixmodule.c has a static
>> implementation of posix_close that is incompatible with musl's.  My
> yes they define posix_ prefixed symbols for internal use
> which are reserved names for the c implementation when
> any standard headers are included
>
> the next posix standard defines posix_close so this is a
> real collision (and will be an issue with every conformant
> libc), but all the other posix_ symbols are wrong there too
>
>> first take on that was to make python use musl's posix_close, which
>> resulted in a very subtle bug leading to a segmentation fault (not
>> to mention all of those lost hours...)  Renaming the module's
>> posix_close to __posix_close solved the problem.  The code that
> these functions have nothing to do with libc: they operate on
> python objects
>
> the symbols should be just renamed but your solution is wrong:
> the __ prefix is still in the reserved name space
>
> use s/posix_/pyposix_/ or similar
>
>
Thanks for pointing this out.  I guess Py_posix_close would be closest 
in spirit to the rest of the python code.

Re: static musl-based gdb and -fPIC

[writeonce]

On 04/21/2014 04:21 AM, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@port70.net> [2014-04-21 09:33:47 +0200]:
>> yes they define posix_ prefixed symbols for internal use
>> which are reserved names for the c implementation when
>> any standard headers are included
>>
>> the next posix standard defines posix_close so this is a
>> real collision (and will be an issue with every conformant
>> libc), but all the other posix_ symbols are wrong there too
> it seems it was already reported and "fixed"
> http://bugs.python.org/issue20594
>
> the fix is broken though
>
>
If I understand correctly, that "fix" is only in the 3.3/3.4 version.  
For llvm/clang/lldb (latest release: 3.4), though, python 2.7 is the 
highest supported version.

zg

Re: static musl-based gdb and -fPIC

[writeonce]

On 04/20/2014 04:31 PM, Rich Felker wrote:
> On Sun, Apr 20, 2014 at 01:03:12PM -0400,writeonce@midipix.org  wrote:
>> Greetings,
>>
>> While building a statically linked musl-based gdb, ld asked that
>> libc.a be recompiled with -fPIC.
> This is a bug in the gdb build process. Despite your request for a
> static gdb, it's trying to build a shared library for something.
> There's a way to disable it (IIRC --disable-gdbserver is a big hammer
> that can do it, and there might be a more fine-grained approach) but
> the real issue is that the build process is broken and doing something
> that can't work.

> Rich
>
>
I built a static gdb (v7.7, passing --disable-gdbserver to configure) 
and _thought_ that everything was fine.  Then I checked the build logs 
and saw that gdb refused to use the present libexpat, libncurses/tinfo, 
and libpython.  In the case of expat, at least, the "solution" was easy, 
albeit unacceptable: temporarily break my local system by renaming 
libexpat.so (so that gdb cannot find it). But for ncurses and python 
that didn't work.

It appears that expat is passed to the linker as a full path 
(/full/path/to/libexpat.so) rather than normally (-lexpat), which makes 
the whole thing break since there is no way to request a static expat 
instead.  Note, however, that this problem is not musl-specific 
(https://sourceware.org/ml/crossgcc/2013-06/msg00003.html).

At this point I am no longer seeking a solution (unless you have one 
ready), but thought I should share this for the record.  As an aside, it 
looks like the static python interpreter is missing some modules as well 
(see, for instance, https://trac.torproject.org/projects/tor/ticket/7557).

zg

Re: static musl-based gdb and -fPIC

[Rich Felker]

On Tue, Apr 29, 2014 at 05:40:06PM -0400, writeonce@midipix.org wrote:
> I built a static gdb (v7.7, passing --disable-gdbserver to
> configure) and _thought_ that everything was fine.  Then I checked
> the build logs and saw that gdb refused to use the present libexpat,
> libncurses/tinfo, and libpython.  In the case of expat, at least,
> the "solution" was easy, albeit unacceptable: temporarily break my
> local system by renaming libexpat.so (so that gdb cannot find it).
> But for ncurses and python that didn't work.
> 
> It appears that expat is passed to the linker as a full path
> (/full/path/to/libexpat.so) rather than normally (-lexpat), which
> makes the whole thing break since there is no way to request a
> static expat instead.  Note, however, that this problem is not
> musl-specific
> (https://sourceware.org/ml/crossgcc/2013-06/msg00003.html).

It's not clear at all to me from your email or from the linked thread
who the passer in "is passed" might be. Is this something broken in
gdb's build script, or expat's pkg-config or similar, or ct-ng, or
something else?

> At this point I am no longer seeking a solution (unless you have one
> ready), but thought I should share this for the record.  As an
> aside, it looks like the static python interpreter is missing some
> modules as well (see, for instance,
> https://trac.torproject.org/projects/tor/ticket/7557).

Static python is not very useful since most important python
extensions are partly implemented as C code, which necessarily must be
dynamically loaded.

Rich

Re: static musl-based gdb and -fPIC

[writeonce]

On 04/29/2014 10:57 PM, Rich Felker wrote:
> On Tue, Apr 29, 2014 at 05:40:06PM -0400, writeonce@midipix.org wrote:
>> I built a static gdb (v7.7, passing --disable-gdbserver to
>> configure) and _thought_ that everything was fine.  Then I checked
>> the build logs and saw that gdb refused to use the present libexpat,
>> libncurses/tinfo, and libpython.  In the case of expat, at least,
>> the "solution" was easy, albeit unacceptable: temporarily break my
>> local system by renaming libexpat.so (so that gdb cannot find it).
>> But for ncurses and python that didn't work.
>>
>> It appears that expat is passed to the linker as a full path
>> (/full/path/to/libexpat.so) rather than normally (-lexpat), which
>> makes the whole thing break since there is no way to request a
>> static expat instead.  Note, however, that this problem is not
>> musl-specific
>> (https://sourceware.org/ml/crossgcc/2013-06/msg00003.html).
> It's not clear at all to me from your email or from the linked thread
> who the passer in "is passed" might be. Is this something broken in
> gdb's build script, or expat's pkg-config or similar, or ct-ng, or
> something else?
Pardon.  The expat pkg-config file (expat.pc) is fine.  It is the gdb 
script that passes /full/path/to/libexpat.so to the linker, which then 
complains about an attempt to statically link a dynamic library.  As far 
as I can tell the problem is somewhere in the configure script under the 
gdb sub-directory.

>
>> At this point I am no longer seeking a solution (unless you have one
>> ready), but thought I should share this for the record.  As an
>> aside, it looks like the static python interpreter is missing some
>> modules as well (see, for instance,
>> https://trac.torproject.org/projects/tor/ticket/7557).
> Static python is not very useful since most important python
> extensions are partly implemented as C code, which necessarily must be
> dynamically loaded.
>
> Rich
>
>
The purpose of building a static python was to make a static libpython.a 
available for gdb.  Given the loss of functionality on both the python 
and gdb ends, it might be better to leave the two dynamically linked as 
they were meant to be...

zg

Re: static musl-based gdb and -fPIC

[Rich Felker]

On Tue, Apr 29, 2014 at 11:26:56PM -0400, writeonce@midipix.org wrote:
> On 04/29/2014 10:57 PM, Rich Felker wrote:
> >On Tue, Apr 29, 2014 at 05:40:06PM -0400, writeonce@midipix.org wrote:
> >>I built a static gdb (v7.7, passing --disable-gdbserver to
> >>configure) and _thought_ that everything was fine.  Then I checked
> >>the build logs and saw that gdb refused to use the present libexpat,
> >>libncurses/tinfo, and libpython.  In the case of expat, at least,
> >>the "solution" was easy, albeit unacceptable: temporarily break my
> >>local system by renaming libexpat.so (so that gdb cannot find it).
> >>But for ncurses and python that didn't work.
> >>
> >>It appears that expat is passed to the linker as a full path
> >>(/full/path/to/libexpat.so) rather than normally (-lexpat), which
> >>makes the whole thing break since there is no way to request a
> >>static expat instead.  Note, however, that this problem is not
> >>musl-specific
> >>(https://sourceware.org/ml/crossgcc/2013-06/msg00003.html).
> >It's not clear at all to me from your email or from the linked thread
> >who the passer in "is passed" might be. Is this something broken in
> >gdb's build script, or expat's pkg-config or similar, or ct-ng, or
> >something else?
> Pardon.  The expat pkg-config file (expat.pc) is fine.  It is the
> gdb script that passes /full/path/to/libexpat.so to the linker,
> which then complains about an attempt to statically link a dynamic
> library.  As far as I can tell the problem is somewhere in the
> configure script under the gdb sub-directory.

You might should check the patches used by sabotage or one of the
other dists using musl. They probably have dealt with the gdb bugs and
probably already have a good fix or workaround.

> >>At this point I am no longer seeking a solution (unless you have one
> >>ready), but thought I should share this for the record.  As an
> >>aside, it looks like the static python interpreter is missing some
> >>modules as well (see, for instance,
> >>https://trac.torproject.org/projects/tor/ticket/7557).
> >Static python is not very useful since most important python
> >extensions are partly implemented as C code, which necessarily must be
> >dynamically loaded.
> >
> The purpose of building a static python was to make a static
> libpython.a available for gdb.  Given the loss of functionality on
> both the python and gdb ends, it might be better to leave the two
> dynamically linked as they were meant to be...

I always just build gdb without python (I'm not much of a python fan).
The ideal solution would be separating python out to run as a separate
process communicating with gdb rather than actually embedding python
in gdb. I really doubt python is anything remotely clean for embedding
into other programs.

Rich

Re: static musl-based gdb and -fPIC

[Zvi Gilboa]

On 04/30/2014 12:07 AM, Rich Felker wrote:
> On Tue, Apr 29, 2014 at 11:26:56PM -0400, writeonce@midipix.org wrote:
>> On 04/29/2014 10:57 PM, Rich Felker wrote:
>>> On Tue, Apr 29, 2014 at 05:40:06PM -0400, writeonce@midipix.org wrote:
>>>> I built a static gdb (v7.7, passing --disable-gdbserver to
>>>> configure) and _thought_ that everything was fine.  Then I checked
>>>> the build logs and saw that gdb refused to use the present libexpat,
>>>> libncurses/tinfo, and libpython.  In the case of expat, at least,
>>>> the "solution" was easy, albeit unacceptable: temporarily break my
>>>> local system by renaming libexpat.so (so that gdb cannot find it).
>>>> But for ncurses and python that didn't work.
>>>>
>>>> It appears that expat is passed to the linker as a full path
>>>> (/full/path/to/libexpat.so) rather than normally (-lexpat), which
>>>> makes the whole thing break since there is no way to request a
>>>> static expat instead.  Note, however, that this problem is not
>>>> musl-specific
>>>> (https://sourceware.org/ml/crossgcc/2013-06/msg00003.html).
>>> It's not clear at all to me from your email or from the linked thread
>>> who the passer in "is passed" might be. Is this something broken in
>>> gdb's build script, or expat's pkg-config or similar, or ct-ng, or
>>> something else?
>> Pardon.  The expat pkg-config file (expat.pc) is fine.  It is the
>> gdb script that passes /full/path/to/libexpat.so to the linker,
>> which then complains about an attempt to statically link a dynamic
>> library.  As far as I can tell the problem is somewhere in the
>> configure script under the gdb sub-directory.
> You might should check the patches used by sabotage or one of the
> other dists using musl. They probably have dealt with the gdb bugs and
> probably already have a good fix or workaround.
Sabotage has several gdb patches, but none of them addresses this. From 
the [deps] section, it looks like sabotage does not aim to have the 
python functionality in its static gdb, and from --disable-tui it looks 
like they encountered a similar problem with ncurses.  The version of 
gdb that I built is a bit newer than sabotage's (7.7 vs. 7.6/7.5), but I 
don't believe that matters.

>
>>>> At this point I am no longer seeking a solution (unless you have one
>>>> ready), but thought I should share this for the record.  As an
>>>> aside, it looks like the static python interpreter is missing some
>>>> modules as well (see, for instance,
>>>> https://trac.torproject.org/projects/tor/ticket/7557).
>>> Static python is not very useful since most important python
>>> extensions are partly implemented as C code, which necessarily must be
>>> dynamically loaded.
>>>
>> The purpose of building a static python was to make a static
>> libpython.a available for gdb.  Given the loss of functionality on
>> both the python and gdb ends, it might be better to leave the two
>> dynamically linked as they were meant to be...
> I always just build gdb without python (I'm not much of a python fan).
> The ideal solution would be separating python out to run as a separate
> process communicating with gdb rather than actually embedding python
> in gdb. I really doubt python is anything remotely clean for embedding
> into other programs.
>
> Rich
Thanks for the tip.  My knowledge of python is actually rather limited; 
I just need it to work since many tests in llvm/clang depend on it...

zg

Re: static musl-based gdb and -fPIC

[John Spencer]

Zvi Gilboa wrote:
> On 04/30/2014 12:07 AM, Rich Felker wrote:
>> You might should check the patches used by sabotage or one of the
>> other dists using musl. They probably have dealt with the gdb bugs and
>> probably already have a good fix or workaround.
> Sabotage has several gdb patches, but none of them addresses this. From 
> the [deps] section, it looks like sabotage does not aim to have the 
> python functionality in its static gdb,

correct.

> and from --disable-tui it looks 
> like they encountered a similar problem with ncurses.  The version of 

no, --disable-tui was added so we don't have 2 nearly identical huge gdb 
binaries in /bin.
in fact we do not even link against ncurses, as gdb can be built against 
the much smaller termcap library.
(however ncurses will be picked up automatically if it was installed 
before building gdb, no problems there either.)

> gdb that I built is a bit newer than sabotage's (7.7 vs. 7.6/7.5), but I 
> don't believe that matters.
> 
>>
>>>>> At this point I am no longer seeking a solution (unless you have one
>>>>> ready), but thought I should share this for the record.  As an

also for the record, the problem you encountered with -fPIC was due to a 
.so built unconditionally during gdbserver compilation, and if you have 
-static in your LDFLAGS, the buildsystem will try to create the .so with 
  both -shared and -static, instead of stripping the -static off for 
that step.
--disable-inprocess-agent can be used to get gdbserver without building 
that dso, which seems rather useless anyway.

--JS