This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 06/19] Define IN_MODULE for translation units that define NOT_IN_libc
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 6 Sep 2014 04:19:44 +0530
- Subject: Re: [PATCH 06/19] Define IN_MODULE for translation units that define NOT_IN_libc
- Authentication-results: sourceware.org; auth=none
- References: <1408618663-2281-1-git-send-email-siddhesh at redhat dot com> <1408618663-2281-7-git-send-email-siddhesh at redhat dot com> <20140822182825 dot 04B6A2C398C at topped-with-meat dot com> <20140822185445 dot GO16835 at spoyarek dot pnq dot redhat dot com> <20140901171944 dot GK4395 at spoyarek dot pnq dot redhat dot com> <20140905185444 dot 0DB9D2C3986 at topped-with-meat dot com>
On 6 September 2014 00:24, Roland McGrath <firstname.lastname@example.org> wrote:
> I can't tell if you're saying this is an actual problem. I don't see why
> symbol-hacks.h would be a problem for interp.c.
It is an actual problem. If interp.c is built with IS_IN(libc) (or
without NOT_IN_libc in the older scheme), symbol-hacks.h injects this
asm ("memmove = __GI_memmove");
asm ("memset = __GI_memset");
asm ("memcpy = __GI_memcpy");
This results in interp.os having undefined references to the __GI_mem*
0000000000000000 *UND* 0000000000000000 __GI_memmove
0000000000000000 *UND* 0000000000000000 __GI_memset
0000000000000000 *UND* 0000000000000000 __GI_memcpy
Those symbols are not exported outside libc.so, thus resulting in a
linker error in every DSO we build, except libc.so.
Maybe the assembler should not be adding these references to the
symbol table since they're only useful if memset, memmove or memcpy
are called, but either way we'll need to work around it in libc.