News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

GoLink problem

Started by nsquare, August 12, 2009, 08:30:21 AM

Previous topic - Next topic

nsquare

Hi Jeremy

I recently converted a MASM32 program into GoAsm, just after GoAsm.exe compiles ok,
GoLink.exe gives this:


Very Sorry, but GoLink had a problem.
...
"Version 0.26 eip=4075A2h"


The program is quite large (about 70,000 lines), and since it is converted from MASM32,
it's hard to tell which code piece caused the problem. What I can guess is that it may be
related to the many complex data structures involved, including multi-levels of internally
nested STRUCT/UNIONs.

The exact version number is GoLink 0.26.11.

And thank you for your time and effort in advance.


jorgon

Hi nsquare

Welcome to GoAsm and to the Forum!

The problem you have encountered should not have happened!
I can see that this is a problem when writing exports to the main output file, but I shall need to run GoLink this end to find exactly what is causing this.
Would you kindly provide me with your GoLink command line or command file and all your object files and res files, so that I can run GoLink on your files my end?  You could either post them here or send them directly to me at the email address which appears when you run GoLink.

Many thanks
Author of the "Go" tools (GoAsm, GoLink, GoRC, GoBug)

nsquare

Hi Jeremy

I've sent the object files to your mailbox.

jorgon

Hi nsquare

Thanks for sending your files.
GoLink was not always committing enough memory for the export tables if there were a lot of exports, hence the error message you saw.
I attach the fix in GoLink 0.26.12

Your executable has 963 exports.  I just wonder if this was intended?

Author of the "Go" tools (GoAsm, GoLink, GoRC, GoBug)

nsquare

Hi, Jeremy

The new version works perfectly now. Thank you very much.

As for the lots of exports, I need to define/implement many data
structures, some of which very complicated, both for data members
and access/modification methods;  I think that a large portion of
them might be reused in the future, so I'd better design them
more carefully now, with reusability in mind.

And thank you again for your help.

BTW, do you think that supportting the below syntax worthwhile ?


invoke func, ..., addr [esi+eax*scale+StructName.MemberName], ...


It can be very convenient when you need to pass addresss of members
of nested structs or struct array to other functions.