The MASM Forum Archive 2004 to 2012

Hello,

I am trying to link my C SDL game using GoLink but it's not working.
\mario sokoban\Release>GoLink.exe /entry mainCRTStartup main.obj jeu.obj fichiers.obj editeur.o
bj

GoLink.Exe Version 0.26.9e - Copyright Jeremy Gordon 2002/9-JG@JGnet.co.uk

Error!
An object file was given to GoLink whose format was not supported (main.obj)
Output file not made

The compiler used was cl from Visual Studio 2008. I usually link with Microsoft linker using the GUI but I want to learn how to link with GoLink.
And one other thing : If I code an assembly function that I use with extern "c" in my program, is it better to link a .lib or a .obj ? I only got it to work using .lib

Hi Mitchi

Would you mind either posting main.obj or sending it to me directly so I can have a look at it, thanks.

As for linking using a .lib, GoLink ignores lib files so if you are successfully linking using a .lib file and not an .obj file, maybe you could remove the name of the file altogether!

Here :
http://mitchi.u7n.org/forGordon.zip

This is my release folder, with all the .obj and .DLL needed in it. If you need everything I have it in .7z on my server but it's bigger (1meg).

Hi Mitchi

Thanks for posting the files.

I can see that the .obj files are created by the "C" compiler within Visual Studio.

Looking at them I can see that they are not in COFF format which is the format expected by GoLink. 

I believe the reason for this is that you have specified the /GL switch in the "C" compiler command line (this is the "whole program optimization" option switch on).  According to the Microsoft article at http://msdn.microsoft.com/en-us/library/0zza0de8.aspx, and this Intel article http://software.intel.com/en-us/articles/intel-c-compiler-compatibility-with-microsoft-visual-c/, object files produced using the /GL switch have a "proprietary intermediate representation".

So you could try switching off "whole program optimization" and see if that makes a difference.

Thank you Gordon ! You were.. right on the mark.


GoLink.Exe Version 0.26.9e - Copyright Jeremy Gordon 2002/9-JG@JGnet.co.uk

Error!
The following symbols were not defined in the object file or files:-
_SDL_Quit
_SDL_FreeSurface
_SDL_Flip
_SDL_UpperBlit
_SDL_FillRect
_SDL_MapRGB
_SDL_WaitEvent
_SDL_WM_SetCaption
_SDL_SetVideoMode
_SDL_WM_SetIcon
_IMG_Load
_SDL_Init
_objectif
_caisseOK
_marioActuel
_carte
_mario
_lastDirection
_position
_positionJoueur
_caisse
_event
_mur
_SDL_EnableKeyRepeat
__imp__exit
_memset
__imp__fclose
__imp__fgets
__imp__fopen
__imp__fprintf
Output file not made


Now I have these errors, but I think I read something somewhere about this name mangling issue, I will probably solve this before anybody comes to help :P
I am converting this SDL game to GoASM. It's hard work but I can use the compiler output to help me and I learn at the same time =D. I've done 1/3 of the work already.

First, I thank Vortex for this undecor tool, it worked well.

Ok, I need help after all  :(

C:\Users\chap\Documents\Visual Studio 2008\Projects\mario sokoban\mario sokoban\
Release>GoLink.exe main.obj jeu.obj editeur.obj fichiers.obj MSVCRT.dll SDL.dll
SDL_image.dll

GoLink.Exe Version 0.26.9e - Copyright Jeremy Gordon 2002/9-JG@JGnet.co.uk

Error!
The following symbols were not defined in the object file or files:-
objectif
caisseOK
marioActuel
carte
mario
lastDirection
position
positionJoueur
caisse
event
mur
Output file not made

These "things" are all global variables I use in my C program. What should I do ? They don't appear in the .h, just in the .c
//Carte dans le heap
int carte[NB_BLOCS_LARGEUR][NB_BLOCS_HAUTEUR];
SDL_Surface* mario[4]; // 4 surfaces pour chacune des directions de mario
SDL_Surface *mur,*caisse,*caisseOK,*objectif,*marioActuel;
SDL_Rect position, positionJoueur;
SDL_Event event;

Mitchi

I'm sorry, but would you mind giving me the object files as they now are, and I shall look into this.

Thanks

Mitchi

If you could kindly let me have the object files before amendment with Vortex's undecorate tool, I will see if I can add a switch to enable GoLink to resolve decorated symbols in object files created by the "C" compiler.  This is actually a different type of decoration which you see with other tools, but you are not the first person who has had problems with this so I do intend to try to sort this out.

Here you go:
http://mitchi.u7n.org/gordon2.zip

Thanks very much Mitchi.

I can now work on your files.

My aim is to permit GoLink to take a mix of MASM, "C", and GoAsm object files, and also to permit MASM and "C" static code libraries used in a GoAsm source file to call other static code libraries also used in GoAsm source, or in other modules.  In each case there is a symbol decoration issue (MASM and "C" object files will have decorated symbols as will code from non-GoAsm static code libraries).

I have a model which will resolve these issues, which does not need a command line switch, and which does not slow down GoLink much at all.  It relies on GoLink recognising GoAsm object files and therefore knowing that there is no automatic decoration in them (a GoAsm object file always has a unique symbol).  But I have to think through the problems which might arise if GoLink is also given object files from other assemblers or compilers which also do not decorate symbols.   These will not necessarily be identifiable.  The problem is as Vortex has said, that the leading underscore decoration may be there on purpose (a user might intend to have a symbol HELLO and also a different symbol _HELLO), instead of it being added automatically by the assembler/compiler.

I would need a way to identify whether particular object files are automatically decorated or not, but I doubt whether this will be possible.

I am working on this though, and may have to change my model to suit the realities of the situation.  I do not want to slow GoLink down for straightforward GoAsm users, so one option may be to add a switch.

Then, if I were you I would add a way for the user to tell GoAsm that the following object files don't have decorated names. Or add it later per request. It's a rare case because GoAsm is the only tool that I know that does this.
:bg

QuoteIt's a rare case because GoAsm is the only tool that I know that does this.

Well, neither NASM or FASM object files are normally decorated.

I decided to add a /mix switch, and will come back to you very soon with this.

Mitchi

I have now added the /mix switch to GoLink see http://www.masm32.com/board/index.php?topic=10770.0.

Would you mind trying this?  It will not be necessary now to use Vortex's undecorate tool (although of course many thanks to Vortex for providing this tool!).

Judging from your third post, you may still find these unresolved:-
__imp__exit
__imp__fclose
__imp__fgets
__imp__fopen
__imp__fprintf

However, these would most likely be in DLL (possibly a run-time library).  You need to give the name of the DLL to GoLink so that it can find these imported functions.

It doesn't really work. The mix switch does remove the leading underscore but when I link the DLL, it doesn't find the function.


C:\Users\chap\Desktop\gordon2>GoLink.exe /mix main.obj fichiers.obj jeu.obj edit
eur.obj SDL.DLL MSVCRT.DLL SDL_image.dll

GoLink.Exe Version 0.26.10 beta- Copyright Jeremy Gordon 2002/9-JG@JGnet.co.uk

Error!
The following symbols were not defined in the object file or files:-
SDL_Quit
SDL_FreeSurface
SDL_Flip
SDL_UpperBlit
SDL_FillRect
SDL_MapRGB
SDL_WaitEvent
SDL_WM_SetCaption
SDL_SetVideoMode
SDL_WM_SetIcon
IMG_Load
SDL_Init
fclose
fgets
fopen
memset
fprintf
objectif
caisseOK
marioActuel
carte
mario
lastDirection
position
positionJoueur
caisse
event
mur
SDL_EnableKeyRepeat
Output file not made

C:\Users\chap\Desktop\gordon2>

Ok Mitchi, thanks for the report.

I can see that your files call procedures in the DLLs which are not being found by GoLink.
This is because GoLink expects "__imp__" type decoration or at least "_CodeName@xx" decoration for such DLL calls if they are decorated at all.  Although I do not use "C", I believe at least the first type of decoration is a result of using the __declspec(dllimport) keyword.
The decoration in your DLL calls is merely of the type "_CodeName", and this may be because in the extrn declaration for these calls in your source code, you have merely used PROC.  This is fine with me as far as syntax is concerned, since I would not force you to use any more complicated syntax than is the very minimum required for the tools that you are using (this being the Go tools tradition).
However, before allowing GoLink to accept mere "_CodeName" decoration, I need to check back a little, because I recall a GoLink user having difficulty in resolving his DLL calls where he was intentionally using a leading underscore, and as a result I made GoLink a little more strict in this respect, so that it required "__imp__" type decoration or at least "_CodeName@xx" decoration.

I'll come back to you very soon.

Ok Mitchi

I now attach GoLink 0.26.10 beta2, which when the "/mix" switch is specified, finds a symbol which is undecorated in a DLL, but which has simple decoration of the type "_CodeLabel" (no @xx at the end or __imp_ at the beginning) in the symbol table of the caller's symbol table.

However using your files, we are still exactly back to the position we were in when you used Vortex's undecor.exe tool.  This demonstrates I think that Vortex's tool and now also GoLink (with the /mix switch) are achieving the same thing.

Currently the missing symbols are:-

objectif
caisseOK
marioActuel
carte
mario
lastDirection
position
positionJoueur
caisse
event
mur

Now you say about these symbols that:-

QuoteThese "things" are all global variables I use in my C program. What should I do ? They don't appear in the .h, just in the .c
//Carte dans le heap
int carte[NB_BLOCS_LARGEUR][NB_BLOCS_HAUTEUR];
SDL_Surface* mario[4]; // 4 surfaces pour chacune des directions de mario
SDL_Surface *mur,*caisse,*caisseOK,*objectif,*marioActuel;
SDL_Rect position, positionJoueur;
SDL_Event event;

I have looked in all the object files and DLLs you have provided, and they are not in those files as "global".
There must be something that you are doing, or not doing, in your "C" source code which makes them local variables and not global variables.
In fact, they appear in the ".asm" listing file editeur.asm provided by your compiler, and in that it is possible to see that they are being treated as local variables only (they are given an offset value on the stack).

I suspect that the reason why they are "local" and not "global" is that (as can be seen from the listing file) the declaration set out above is made after the opening braces in line 20 of your C source file editeur.c - would you mind checking this?  I am not a "C" programmer but I do use javascript and this seems to be the remaining culprit!





[attachment deleted by admin]

Thanks gordon, the mix switch works now, it gets me as far as undecor was getting me now.
The missing symbols we are talking about :


objectif
caisseOK
marioActuel
carte
mario
lastDirection
position
positionJoueur
caisse
event
mur


These symbols are really global variables in a .c file. In editeur.asm, they are used too but they are all allocated on the stack using mov d[esp+something], ebx.
If you don't believe me, the lastDirection variable can only be found in jeu.c and it's not present in editeur.c.
I made of my my code modifications in jeu.c and I used these variables as global variables.

Here is jeu.c and editeur.c if you want to take a better look.

editeur.c :
http://pastebin.ca/1328645
jeu.c :
http://pastebin.ca/1328646

Now, this is where I think the problem is. If you take at jeu.asm you'll see this.
And it's exactly the same as our error message.


_DATA SEGMENT
COMM _objectif:DWORD
COMM _caisseOK:DWORD
COMM _marioActuel:DWORD
COMM _carte:DWORD:090H
COMM _mario:DWORD:04H
COMM _lastDirection:DWORD
COMM _position:QWORD
COMM _positionJoueur:QWORD
COMM _caisse:DWORD
COMM _event:BYTE:014H
COMM _mur:DWORD
_DATA ENDS


Basically, GoLink as it is right now should be able to link object files created by VC++ as long as there are no global variables in the source code.
Sorry for the wait, I was away for a couple of days watching baseball.

Ok Mitchi

Thanks for the report.
It does seem possible that GoLink is missing some symbols created by a "C" compiler which it ought to deal with.
I'll look into this and come back to you.

Hi Mitchi

As I believe you anticipated, I found that your object files contained "common symbols", which were not being picked up by GoLink.

I have now added support for these when the /mix switch is used see http://www.masm32.com/board/index.php?topic=10770.

However, GoLink didn't find an entry point in your files defined by the .drectve section - perhaps you supplied one in the command file?

C:\Users\chap\Desktop\gordon2>GoLink.exe /entry _SDL_main /mix main.obj fichiers
.obj jeu.obj editeur.obj SDL.DLL MSVCRT.DLL SDL_image.dll

And it worked, it did a 9 ko .exe (better than MS linker ) :)
The program starts , the main menu displays but I kept getting exception problems when I wanted to play so I fired Ollydbg to investigate... All the code is here, there is no problem. The problem lies with my switch instruction. When I use JMP [401CA0+EAX*4], the addresses in the jump table are not the right ones. It was to be expected, and I won't ask you to fix this as it would be quite difficult...

Thanks for your report, Mitchi.