NASM + TLINK32

[wyvern666]

Hi all. Im having some troubles when linking mi NASM code with TLINK32. I have a simple example program here:

Code: [Select]

[CPU 386]     ;ok, not needed
[GLOBAL ..start]      ;i think dont needed too?

;[EXTERN _MessageBoxA@16]   TRYIED THIS
;[EXTERN _ExitProcess@4]

[SEGMENT idata use32]  ; TRYED witouth this
[EXTERN MessageBoxA]
[IMPORT MessageBoxA user32.dll]
[EXTERN ExitProcess]
[IMPORT ExitProcess kernel32.dll]

[SECTION code use32]
..start:                               ; entry point for OMF
        PUSH 00000040h
        PUSH title               
        PUSH msg               
        PUSH 00000000h           
        CALL MessageBoxA 
             
        PUSH 00000000h       
        CALL ExitProcess 

[SECTION data use32]
        title  db 'Titulo', 00h
        msg db 'Mensaje', 00h
The cmd line:

Code: [Select]

>nasm -f obj app.asm -o app.obj
>tlink32 /Tpe /aa /c app.obj,,,import32.lib
So TLINK32 is "successfully" linking the code... at least i think that kause it says nothing, so i think there is no error. The problem is that the generated app.exe is not running, it does nothing, so i checked with OllyDbg and the Win API addreses werent resolved. there is no thing like ".idata" import section.

I think im a close to do this right, after all TLINK32 works with OMF, and i am using the OMF(-f obj) format with NASM. But maybe there is some little detail i am not getting here, any help please?.

Thanks

[Frank Kotler]

Well... it was a long time ago that I last tried anything like this, and my memory may be faulty. There are some "weird" things about Nasm's implementation of the 32-bit extensions to OMF (-f obj). If possible, I would suggest using "-f win32" - and a different linker. Or, possibly use "-f win32" and Agner Fog's "objconv" to convert the object file to OMF. It seems to me that Borland's tools are more sensitive to Nasm's "oddities" than other linkers(?). Alink seemed to work better(?).

One "problem" I see is that if we use "import", we need to "call [foo]" instead of "call foo"! I have no clear idea why this should be so. My recollection is that if we use "import", we don't need to link with a library(?)... at least with Alink, this is true.

Code: [Select]

EXTERN MessageBoxA
IMPORT MessageBoxA user32.dll
EXTERN ExitProcess
IMPORT ExitProcess kernel32.dll

SECTION code use32 class=CODE
..start:                               ; entry point for OMF
        PUSH 00000040h
        PUSH title               
        PUSH msg               
        PUSH 00000000h           
        CALL [MessageBoxA]
             
        PUSH 00000000h       
        CALL [ExitProcess] 

SECTION data use32
        title  db 'Titulo', 00h
        msg db 'Mensaje', 00h

I've cut your code down to what I remember as the "minimum" of what I think "used to work" (with Alink, at least - not sure about Tlink32). See if it helps...

If you really need to use Borland's tools (delphi, in particular), try "-f win32" and "objconv"...

http://www.agner.org/optimize/#objconv

If you're not committed to Borland's tools, try "-f win32" and GoLink. This seems to be the most "popular" linker, these days (pity it isn't open source!). The NASMX package should include it, or get it from Jeremy Gordon's site... Hmmm, Jeremy's site seems to have disappeared(?)... Try NASMX.

Let us know how it goes, if you would...

Best,
Frank

[wyvern666]

Thanks for your help. But now i have the following problem:

"Warning: No entry Point."

This is because i couldnt use "..start" with the "-f win32" format of NASM, so i changed to "start" and now the program cant start. And TLINK32 havent a entry point switch... any suggestion for this little problem?

By the way, i once had the exact problem with FASM, the convertion from COFF to OMF doesnt mantain a "entry point", so at the end you link witout it.

[wyvern666]

After a litle thinking... mi problem (and it is an old problem) is basically HOW to tell OBJCONV what label to use as "entry point". I mean, if you can convert COFF to OMF you must be able to specify the entry point in some way, but i dont know what command line parameter use in OBJCONV.

[Frank Kotler]

Good question! As you probably know, Nasm uses the special symbol "..start" - in "-f obj" only! - as the entrypoint. Nasm knows that this should be "global", so you don't need to explicitly declare it "global". Masm/Tasm, in contrast, use the "end foo" directive to indicate that "foo" is the entrypoint. If Tlink32 doesn't have an option to name the entrypoint, it must(?) know some "standard" name (no?). It might be possible to discover this name by dumping/disassembling a Tasm-assembled object or executable. (this name, if any, would need to be declared "global"). That's all I can think of to suggest...

Best,
Frank

[Frank Kotler]

Disassembling tlink32.exe itself with objconv, I see "Entry_point" used. Try that...

Best,
Frank

[wyvern666]

Sorry Frank, but im afraid it is not working...  .

Some time ago y checked the OMF specifications, there it says the MODEND—Module End Record record have some info about the entry point, this record start with id code "8F". From the specs:

Consider the MODEND record of a simple HELLO.ASM program:
0 1 2 3 4 5 6 7 8 9 A B C D E F
0000 8A 07 00 C1 00 01 01 00 00 AC.....
...
Byte 03H contains 0C1H (11000001B). Bit 7 is set to 1, indicating that this module is the main module of the
program. Bit 6 is set to 1, indicating that a Start Address subfield is present. Bit 0 is set to 1, indicating that the
address referenced in the Start Address subfield must be fixed up by the linker.
...

So if a COFF is converted to OMF, i guess OBJCONV is not setting up the bits needed for a start address..., maybe write this MODEND record by hand would work?. Or u think maybe i must ask to the OBJCONV author?

[wyvern666]

By the way, please explaing me the difference between "[directive ...]" and "directive ..." without the "[]", and why the "class=Data".

[Frank Kotler]

You seem to know a lot more about OMF than I do. I guess hand editing the record might work - seems like the "hard way". Asking Agner Fog might be a good idea!

"[directive ...]" is the "raw" form, "directive ..." is a macro. In the case of "section(segment) ...", the macro sets "__SECT__", as well as adding the "[]"s. In the case of "extern foo bar baz", the macro breaks it up into "[extern foo]", "[extern bar]", "[extern baz]" - the "raw" form allows only one parameter. Nasm's "struc" macro uses "__SECT__", so it is considered advisable to use the macro form for section/segment. In general, it doesn't make too much difference. I removed the "[]" from your code only because it looks more like what I remember working...

I really don't know what "class=CODE" does - sets a bit in the record, I guess. I recall that Ollydbg complains "entrypoint not in code segment" without it. I think objconv is happier with it than without, too. That's using Alink rather than Tlink32, though...

I wish I had better answers for you!

Best,
Frank