Linux Shared Library

[mene mene tekel]

Hi,

I have nasm code successfully compiles to a win32 DLL. Now, I habe to provide this code on a Linux Shared Library (they call it a .so file) to be accessed by a tomcat application server (32 bit). OK, I have no glue about Linux. From the nasm manual I learnt about sections (instead of segments) and nasm -elf produces a .o object file (would be enough for me, also) but it did not run on the Linux server - link problems. Perhaps, it has to do with this suff arround GOT - but is completey unclear to me. All nasm examples generate .out executables, doesn't help me.

Unfortunately, I've no Linux available to test some stuff by myself.

If it's not big thing it would be great if somebody could post a code example i.e. a function "giveback" taking an Int32 argument and giving it back again like
_StdCall Int32 giveback(Int32 number)
This entry point giveback should be exposed by the resulting .o object file and the nasm.exe and alink.exe command line commands to generate this .o from the .asm would be helpful, also.
(please, no gcc usage, I don't have any Linux tool available on my win32 computer, I can use nasm.exe and alink.exe, only)

Many thanks for help,
martin

[Frank Kotler]

Nasm.exe will produce ELF linkable object files, regardless of what OS it's running on. Alink.exe, however, has *no* idea how to make a shared object out of it. You're SOL on that score. Fergeddiit!

It "should" be possible to compile ld to run under Windows as a "cross linker". Good luck, even if you use gcc... "should" be possible even with whatever non-gcc compiler you're using... says right in the glossy brochure that C is portable, right?

I sympathize with your position. *I* can't (won't, I should say) test anything on Windows. However, as it happens, I've got more versions of ld than you can shake a stick at. I've seen an example of a "simple" shared library. I seem to recall that the command line to ld involves "--shared". We've gotta move our gem to some directory mentioned in /etc/ldconf and then do ldconfig to "activate" it.

However, there's more to it than that. Unless I'm mistaken, the difference between a PE and a .dll is that the latter has a relocation section. An .so, AFAIK, does not have a relocation section and must be position independent code. "GOT" and friends are supposed to assist in this... I'm afraid I don't "get" how to use 'em...

If you had a friend who was running Linux, say fbkotler at users.sf.net or at verizon.net... you might be able to get him to run your code past ld and report back what the error message was, at least...

(incidentally, "segment" and "section" are exact aliases to Nasm. There are differences - *big* differences - between Windows and Linux, but this ain't one of 'em)

Best,
Frank

P.S. You can use a "live CD" to test stuff under Linux, without having to "install" it...

[mene mene tekel]

Hi Frank,

Thanks for your fast response - made me sure that the problem is not our .o from nasm. You are right, I can generate an ELF linkable object. When I compile i.e. this example code

bits  32                            ;32bit code
global      rtnSeven
            section .data
            section .text
%define     pObj        ebp+12                  ;jobject = UInt32
%define     pEnv        ebp+8                   ;JNIEnv  = UInt32
rtnSeven:
            push  ebp
            mov   ebp,  esp
            mov   eax,  dword 7                 ;Return 7
            mov   esp,  ebp
            pop   ebp
.rtn        ret   4*2

with the -felf32 option. I then have a .o we can use on the Linux server to link a .so library using ld!
(the two extra arguments JNIEnv and jobject are necessary for the Java JNI interface - forget about it, here)

OK, but tomcat could not link our .so ...
Reason for that, we found out now: the Linux name of the library *must* start with the prefix 'lib'!
LOL - omitting the .so extension is ok is some way, but having to name rtnSeven.so as libRtnSeven.so ...
I will remember that next time a Linux guy blame me that Microsoft identifies files by their extensions ;-)

But, seriously, when I take a look into the .o generated by nasm with the editor, I see some "strange" things:

1. The .o contains *all* labels used in the .asm file, in the above example two labels:
rtnSeven
rtnSeven.rtn
regardless of the global instruction stating that only rtnSeven should be exposed! Every label is exposed! This makes no sense, isn't it?

2. When I define variables (labels) in the .data section, same with those labels: *all* present in the .o!

3. The .o contains *all* equ definitions from the file, even regardless whether they are used or not in the code. This means, when I have an include file with some definitions like
NULL  equ 0x00000000
TRUE  equ 0x00000001
FALSE equ 0x00000000
then the .o file exposes i.e. a 'label' named NULL or at least the .o file cares a parameter name NULL. But shouldn't NULL be replaced with 0x0000000 by the preprocessor and so will never occur in a library? At least nasm behaves like that when generating .obj files for PE!
Because I have a lot of such equates they blow up the resulting .o especially those of them never used in the code!
Can that behavior be correct?

00006d0: 6d00 5452 5545 0046 414c 5345 004e 554c  m.TRUE.FALSE.NUL <-- equ used in code
00006e0: 4c00 444c 4c5f 5052 4f43 4553 535f 4445  L.DLL_PROCESS_DE
00006f0: 5441 4348 0044 4c4c 5f50 524f 4345 5353  TACH.DLL_PROCESS <-- equ never used in code
0000700: 5f41 5454 4143 4800 444c 4c5f 5448 5245  _ATTACH.DLL_THRE
0000710: 4144 5f41 5454 4143 4800 444c 4c5f 5448  AD_ATTACH.DLL_TH
0000720: 5245 4144 5f44 4554 4143 4800 7056 6572  READ_DETACH.pVer <-- .data section labels
0000730: 7369 6f6e 0075 4b65 7956 616c 7565 0064  sion.uKeyValue.d
0000740: 4375 746f 6666 5800 6443 7574 6f66 6659  CutoffX.dCutoffY

I use "The Netwide Assembler 0.99.05"

Would be great you could help to make my (now working) .o libs more perfect.

Cheers,
martin

[mene mene tekel]

Hi, me again!

no response so far? Hmmm... ok, did I miss a simple "-s strip option" or something like that to eliminate all these useless equates and labels from the elf .o lib? Or is it an (un)known problem with the nasm.exe -felf32 ?

I feel not good with all my local label names in my .o lib ... Nobody an idea how to make the "global/extern" mechanism working correctly - just like in nasm.exe -fobj?

Thanks,
martin