Exporting symbols

[Dan Timis]

Hi,

We need to have a library that links statically to a wine application.  
The wine application is an .exe.so, so everything becomes in the end an 
exe.so.  The problem we have is that all the symbols are exposed.

I have very little experience with Windows, but I understand that with 
a Windows DLL you can export certain functions, while hiding the 
others.  I know that's also true for the Mac.

Is there any way to export only the functions that are called by the 
code we link to, without exposing the internal workings?  Ideally we 
would like to be able to provide a static library created with ar or 
ranlib, link that library with other object files to create a .exe.so 
for wine, but when you do "nm" on the resulting .exe.so you would not 
see all the inner workings of our library.

Is that possible?

Thanks,

Dan Timis
Muse Research, Inc.

[Dan Timis]

Oops.  I misspoke.

I was relating what a colleague told me.  After I sent the message I 
thought I would try it myself (I should have tried before).  Running 
"strip" does remove the symbols and running "nm" after that does not 
show any symbols.

My colleague clarified the problem.  After running strip if you run 
"strings -a" all the names of the function calls are still there as 
strings.

So the real question is, can we get rid of those strings?  What is 
their role?

Thanks,

Dan Timis
Muse Research, Inc.

On Wednesday, May 12, 2004, at 04:34 PM, Dan Timis wrote:
> Hi,
>
> We need to have a library that links statically to a wine application. 
>  The wine application is an .exe.so, so everything becomes in the end 
> an exe.so.  The problem we have is that all the symbols are exposed.
>
> I have very little experience with Windows, but I understand that with 
> a Windows DLL you can export certain functions, while hiding the 
> others.  I know that's also true for the Mac.
>
> Is there any way to export only the functions that are called by the 
> code we link to, without exposing the internal workings?  Ideally we 
> would like to be able to provide a static library created with ar or 
> ranlib, link that library with other object files to create a .exe.so 
> for wine, but when you do "nm" on the resulting .exe.so you would not 
> see all the inner workings of our library.
>
> Is that possible?
>
> Thanks,
>
> Dan Timis
> Muse Research, Inc.

[Dan Timis]

I'm really, really sorry for this.  I should have done my research 
first.

After running strip on the .exe.so if we do nm -D all the symbols are 
still there.  Is there any way to get rid of the ones that are not 
needed for dynamic linking?

Thanks,

Dan

On Wednesday, May 12, 2004, at 05:43 PM, Dan Timis wrote:
> Oops.  I misspoke.
>
> I was relating what a colleague told me.  After I sent the message I 
> thought I would try it myself (I should have tried before).  Running 
> "strip" does remove the symbols and running "nm" after that does not 
> show any symbols.
>
> My colleague clarified the problem.  After running strip if you run 
> "strings -a" all the names of the function calls are still there as 
> strings.
>
> So the real question is, can we get rid of those strings?  What is 
> their role?
>
> Thanks,
>
> Dan Timis
> Muse Research, Inc.
>
> On Wednesday, May 12, 2004, at 04:34 PM, Dan Timis wrote:
> > Hi,
> >
> > We need to have a library that links statically to a wine 
> > application.  The wine application is an .exe.so, so everything 
> > becomes in the end an exe.so.  The problem we have is that all the 
> > symbols are exposed.
> >
> > I have very little experience with Windows, but I understand that 
> > with a Windows DLL you can export certain functions, while hiding the 
> > others.  I know that's also true for the Mac.
> >
> > Is there any way to export only the functions that are called by the 
> > code we link to, without exposing the internal workings?  Ideally we 
> > would like to be able to provide a static library created with ar or 
> > ranlib, link that library with other object files to create a .exe.so 
> > for wine, but when you do "nm" on the resulting .exe.so you would not 
> > see all the inner workings of our library.
> >
> > Is that possible?
> >
> > Thanks,
> >
> > Dan Timis
> > Muse Research, Inc.

[Dmitry Timoshkov]

"Dan Timis"  wrote:
> I'm really, really sorry for this.  I should have done my research 
> first.
>
> After running strip on the .exe.so if we do nm -D all the symbols are 
> still there.  Is there any way to get rid of the ones that are not 
> needed for dynamic linking?

Actually that's a question for binutils mailing list. I was researching
that problem some time ago and found that dynamic linker has a switch
'--retain-symbols-file FILENAME' to leave only listed in the FILENAME
names in the SYMBOL TABLE. But according to 'objdump -xstTR' DYNAMIC
SYMBOL TABLE still has all global symbols listed. I'd call it a limitation
of ELF format, which has no a concept of exported symbols.

[Mike Hearn]

On Wed, 12 May 2004 19:45:42 -0700, Dan Timis wrote:
> After running strip on the .exe.so if we do nm -D all the symbols are 
> still there.  Is there any way to get rid of the ones that are not 
> needed for dynamic linking?

Dmitry is right, ask on the binutils list. However if you hide symbols
using the --retain-symbols-file trick or versioning scripts, you may be
able to mangle the symbol table without breaking anything. Why not try it
- write a program to scan .symtab for the symbols you want to hide and
scramble the strings. I'd be interested to hear the results.

ELF was not really designed for code obfuscation like this though. I think
nvidia use a preprocessor to mangle symbols in the final binary, if you
ask them they may be willing to tell you how it's done (maybe even give
you the code).

thanks -mike