[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53236EF2.4030606@gcom.com>
Date: Fri, 14 Mar 2014 16:04:50 -0500
From: David Grothe <dave@...m.com>
To: musl@...ts.openwall.com
CC: Support at Gcom <support@...m.com>
Subject: Re: Static linking of musl with code compiled using GNU header
files
I built a shim module that defined all the undefined "__" routines that
showed up in my link. Then all my programs linked successfully. But
when I went to run one of my daemon processes it got a segv in the
malloc code, as follows.
Program terminated with signal 11, Segmentation fault.
#0 0x0811cd5d in unbin (c=0x9b53898, i=8) at src/malloc/malloc.c:242
#1 0x0811d266 in malloc (n=112) at src/malloc/malloc.c:371
#2 0x0804b3ce in ssd_malloc_fcn (nbytes=16, file=0x81348e6 "../pi.c",
linenr=2398) at ../pi.c:632
#3 0x0804b597 in ssd_zalloc_fcn (nbytes=12, file=0x81348e6 "../pi.c",
linenr=2398) at ../pi.c:687
#4 0x0804b5e2 in ssd_calloc_fcn (n_memb=1, memb_size=12, file=0x81348e6
"../pi.c", linenr=2398) at ../pi.c:696
#5 0x0804ef18 in ss_setup_code_path (size=1024) at ../pi.c:2398
#6 0x080548be in register_connections () at ../pi.c:5074
#7 0x0805a2b8 in main (argc=2, argv=0xbfae15f4) at ../pi.c:7393
(gdb) p *c
$1 = {psize = 17, csize = 144, next = 0x81a3990, prev = 0x1}
(gdb) p mal
$2 = {brk = 163028992, heap = 0x9b53008, binmap = 35184372089088, bins =
{{lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head =
0x81a3920, tail = 0x81a3920}, {lock = {0, 0},
head = 0x81a3930, tail = 0x81a3930}, {lock = {0, 0}, head =
0x81a3940, tail = 0x81a3940}, {lock = {0, 0}, head = 0x0, tail = 0x0},
{lock = {0, 0}, head = 0x81a3960, tail = 0x81a3960}, {
lock = {0, 0}, head = 0x81a3970, tail = 0x81a3970}, {lock = {0,
0}, head = 0x81a3980, tail = 0x81a3980}, {lock = {0, 0}, head =
0x9b53898, tail = 0x9b53898}, {lock = {0, 0},
head = 0x81a39a0, tail = 0x81a39a0}, {lock = {0, 0}, head =
0x81a39b0, tail = 0x81a39b0}, {lock = {0, 0}, head = 0x81a39c0, tail =
0x81a39c0}, {lock = {0, 0}, head = 0x81a39d0,
tail = 0x81a39d0}, {lock = {0, 0}, head = 0x81a39e0, tail =
0x81a39e0}, {lock = {0, 0}, head = 0x81a39f0, tail = 0x81a39f0}, {lock =
{0, 0}, head = 0x81a3a00, tail = 0x81a3a00}, {lock = {0,
0}, head = 0x81a3a10, tail = 0x81a3a10}, {lock = {0, 0}, head =
0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3a30, tail = 0x81a3a30},
{lock = {0, 0}, head = 0x81a3a40, tail = 0x81a3a40},
{lock = {0, 0}, head = 0x81a3a50, tail = 0x81a3a50}, {lock = {0,
0}, head = 0x81a3a60, tail = 0x81a3a60}, {lock = {0, 0}, head = 0x0,
tail = 0x0}, {lock = {0, 0}, head = 0x81a3a80,
tail = 0x81a3a80}, {lock = {0, 0}, head = 0x81a3a90, tail =
0x81a3a90}, {lock = {0, 0}, head = 0x81a3aa0, tail = 0x81a3aa0}, {lock =
{0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0},
head = 0x81a3ac0, tail = 0x81a3ac0}, {lock = {0, 0}, head =
0x81a3ad0, tail = 0x81a3ad0}, {lock = {0, 0}, head = 0x81a3ae0, tail =
0x81a3ae0}, {lock = {0, 0}, head = 0x81a3af0,
tail = 0x81a3af0}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock
= {0, 0}, head = 0x81a3b10, tail = 0x81a3b10}, {lock = {0, 0}, head =
0x81a3b20, tail = 0x81a3b20}, {lock = {0, 0},
head = 0x81a3b30, tail = 0x81a3b30}, {lock = {0, 0}, head =
0x81a3b40, tail = 0x81a3b40}, {lock = {0, 0}, head = 0x81a3b50, tail =
0x81a3b50}, {lock = {0, 0}, head = 0x81a3b60,
tail = 0x81a3b60}, {lock = {0, 0}, head = 0x81a3b70, tail =
0x81a3b70}, {lock = {0, 0}, head = 0x81a3b80, tail = 0x81a3b80}, {lock =
{0, 0}, head = 0x81a3b90, tail = 0x81a3b90}, {lock = {0,
0}, head = 0x81a3ba0, tail = 0x81a3ba0}, {lock = {0, 0}, head =
0x81a3bb0, tail = 0x81a3bb0}, {lock = {0, 0}, head = 0x81a3bc0, tail =
0x81a3bc0}, {lock = {0, 0}, head = 0x81a3bd0,
tail = 0x81a3bd0}, {lock = {0, 0}, head = 0x9b78888, tail =
0x9b78888}, {lock = {0, 0}, head = 0x81a3bf0, tail = 0x81a3bf0}, {lock =
{0, 0}, head = 0x0, tail = 0x0} <repeats 17 times>},
brk_lock = {0, 0}, free_lock = {0, 0}}
I can supply more details as needed.
Thanks,
Dave
On 3/14/2014 1:52 PM, David Grothe wrote:
> Thanks for the suggestions.
>
> My musl build did not include a libgcc:
>
> linuxsvr:dave:musl-0.9.15> find . -name '*libgcc*'
> linuxsvr:dave:musl-0.9.15>
>
> It is correct that something in the GNU headers changed "signal" into
> "sysv_signal" without my knowledge.
>
> My code base is several million lines of code and I have many other
> projects to do that are higher priority than porting to another set of
> header files. It would be a few days worth of effort and I just have
> other things to do right now.
>
> That said I do have a reason for wanting static linking, so maybe I
> will find the time to do the port some time. (I tried just aiming my
> build at the musl include directory and it did not "just work".)
>
> I can act on the suggestions made and see how that helps. But what
> about libgcc?
>
> Thanks,
> Dave
>
> On 3/14/2014 11:29 AM, Szabolcs Nagy wrote:
>> * David Grothe<dave@...m.com> [2014-03-14 10:47:31 -0500]:
>>> I have a very large code base that I have been compiling on Linux
>>> using the standard GNU C compiler [gcc (Ubuntu/Linaro
>>> 4.6.3-1ubuntu5) 4.6.3]. I have been using shared object libraries,
>>> but for reasons of software support I would now like to link all my
>>> commands (a couple of dozen) and daemons using static libraries so
>>> that the code files are self-contained and can be copied, along with
>>> a core file, to any server back in my shop for analysis. With
>>> dynamic libraries I have to have exactly the same version of libc
>>> installed on the machine that I use to examine the core file as were
>>> present on the machine that generated the core file, or else gdb
>>> will not produce a stack back trace with file and line number
>>> information. So much for the background.
>>>
>>> I really don't want to port my code base to using the musl header
>>> files. I want to keep compiling with the GNU headers. When I do
>> compiling with the gnu headers is broken and
>> it depends on the cflags used
>>
>>> this and link my-huge-program.o with musl libc.a I get the following
>>> list of unresolved externals:
>>>
>>> U __divdi3
>> comes from libgcc.a, if it's missing you have a toolchain issue
>>
>>> w __fini_array_end
>>> w __fini_array_start
>> i think musl supports init/fini arrays
>> (see src/exit/exit.c)
>>
>>> U __moddi3
>> libgcc
>>
>>> U __sysv_signal
>> you may want to replace it with signal
>>
>>> U __udivdi3
>>> U __umoddi3
>> libgcc
>>
>>> U __vfprintf_chk
>>> U __vsnprintf_chk
>>> U __vsprintf_chk
>> there are many _chk functions for _FORTIFY_SOURCE, musl may provide
>> these eventually, until then you can add your own chk.o with dummy
>> implementations (possibly with the safety checks i omit here):
>>
>> int __vfprintf_chk(FILE *f, int flag, const char *fmt, va_list ap)
>> {
>> return vfprintf(f, fmt, ap);
>> }
>> int __vsnprintf_chk(char *s, size_t n, int flag, size_t size, const char *fmt, va_list ap)
>> {
>> return vsnprintf(s, n, fmt, ap);
>> }
>> int __vsprintf_chk(char *s, int flag, size_t size, const char *fmt, va_list ap)
>> {
>> return vsprintf(s, fmt, ap);
>> }
>>
>>> U __sysv_signal
>> use signal
>>
>>> So, I am wondering if the musl library could at some point provide
>>> these routines to enable users to do what I am trying to do.
>> compiling with glibc headers and then linking to musl
>> cannot be supported in general, because of ABI compat issues
>>
>> (eg glibc headers define PTHREAD_*_INITIALIZER macros that hardcode
>> glibc internal ABI at compile time that does not match musl)
>>
>> if you are sure you don't have such ABI breakage (see glibc
>> vs musl differences on the wiki) then you may get away by
>> adding a glibc-compat.o to your musl build
>>
>>> Any possibility of that?
>>>
>>> Thanks,
>>> Dave
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
