[06/19] Define IN_MODULE for translation units that define NOT_IN_libc

Make sure that all instances where NOT_IN_libc is defined also defines
IN_MODULE to facilitate removal NOT_IN_libc in future passes.

Verified that the generated code is unchanged on x86_64.

	* elf/Makefile (libof-sotruss-lib): Set as extramodules.
	(libof-interp): Likewise.
---
 elf/Makefile | 2 ++
 1 file changed, 2 insertions(+)

interp.c is in fact in libc.  I don't see why libof-interp should be set at
all.

You also don't explain why libof-sotruss-lib matters, though that at least
is correct in the abstract.

On Fri, Aug 22, 2014 at 11:28:24AM -0700, Roland McGrath wrote:
> interp.c is in fact in libc.  I don't see why libof-interp should be set at
> all.

I remember the build breaking when I made it libc.  I'll check again,
but I remember concluding that it couldn't be libc.

> You also don't explain why libof-sotruss-lib matters, though that at least
> is correct in the abstract.

It doesn't actually matter per-say, but I've added it with the
assumption that it might be needed in future.

Siddhesh

On Sat, Aug 23, 2014 at 12:24:45AM +0530, Siddhesh Poyarekar wrote:
> On Fri, Aug 22, 2014 at 11:28:24AM -0700, Roland McGrath wrote:
> > interp.c is in fact in libc.  I don't see why libof-interp should be set at
> > all.
> 
> I remember the build breaking when I made it libc.  I'll check again,
> but I remember concluding that it couldn't be libc.

I just checked again.  The compilation always includes libc-symbols.h,
which adds symbol hacks for memcpy, memset and memmove, that become
internal references when IS_IN(libc).

Siddhesh

> On Sat, Aug 23, 2014 at 12:24:45AM +0530, Siddhesh Poyarekar wrote:
> > On Fri, Aug 22, 2014 at 11:28:24AM -0700, Roland McGrath wrote:
> > > interp.c is in fact in libc.  I don't see why libof-interp should be set at
> > > all.
> > 
> > I remember the build breaking when I made it libc.  I'll check again,
> > but I remember concluding that it couldn't be libc.
> 
> I just checked again.  The compilation always includes libc-symbols.h,
> which adds symbol hacks for memcpy, memset and memmove, that become
> internal references when IS_IN(libc).

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.

On 6 September 2014 00:24, Roland McGrath <roland@hack.frob.com> 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
code:

asm ("memmove = __GI_memmove");
asm ("memset = __GI_memset");
asm ("memcpy = __GI_memcpy");

This results in interp.os having undefined references to the __GI_mem*
functions above:

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.

Siddhesh

> Those symbols are not exported outside libc.so, thus resulting in a
> linker error in every DSO we build, except libc.so.

Oh, I see.  I'd forgotten we were using interp.c for any other libraries.
I think nowadays we actually should not be, because none of the others has
an entry point set that actually works (alas, dlfcn/eval.c is long defunct).
So let's just fix that first.