[M3devel] more assembly symbols please?

Jay jayk123 at hotmail.com
Sun Jan 20 13:08:20 CET 2008


Exact same result with MS link.
Quite the succesful interop. :)
I copied in all the relevant *o and *obj files (avoiding mklib/*.lib as a factor) to C:\dev2\cm3.2\m3-sys\cm3\NT386GNU and selectively from \mingw\lib (like just in the end libcgcc.a for arithmetic helpers) and then
 
link -out:cm3.exe  *.io *.mo *.obj comctl32.lib gdi32.lib user32.lib wsock32.lib netapi32.lib libgcc.a kernel32.lib advapi32.lib msvcrt.lib
prints the same thing, crashes due to the same data.
 
Which is to say, in the great toolset debate, you can use the gcc back end (and as) for Modula-3, but then either ld or link and probably cl or gcc. :)
Except..it still doesn't quite work..
 
I guess "collect2" is a synonym for ld?
 
 - Jay


From: jayk123 at hotmail.comTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] more assembly symbols please?Date: Sun, 20 Jan 2008 04:56:00 +0000



MinGWin (GNU ld)I might try putting together a totally Cygwin system to see if that works, to try to understand where the problem is.This really shouldn't be so hard from the information I have though.. :(Fishing with Cygwin should not be needed..I can dump the ModuleInfo from C and I can see where the bad one is, I just need to trace through its creation to find where it goes bad...I assume it is NOT related to the fact that assembly/object file names get truncated to 8 characters, RTHeapInfo.m3 => RTHeapIn.m3 but so far that's all I see to "what is special about RTHeapInfo?". - Jay

> CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] more assembly symbols please?> Date: Sat, 19 Jan 2008 18:46:59 -0500> To: jayk123 at hotmail.com> > Which linker are you using? Could that be a factor?> > On Jan 19, 2008, at 1:49 PM, Jay wrote:> > > Thanks. m3cg -y for full tracing also dumps relevant stuff at the end.> > I'll try m3cgcat too. I should just be able to build/run an NT386 > > version.> > My C tracing does "prove" the problem is RTHeapInfo, but I still > > haven't figured out why.> > I've started skimming the code that builds that data...still a ways > > off from solving this I think.> > I have some suspicion the linker is moving things around that were > > otherwise correct, but I am far from proving that or fixing it.> > I'd like to first verify that the "m3front" / m3cg output is correct.> > The lack of labels in the as actually is a counter point to the > > movement theory, hard for linker to get a handle on anything to > > move around, it's just one blob.> >> > - Jay> >> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] more assembly symbols please?> > > Date: Sat, 19 Jan 2008 12:33:08 -0500> > > To: jayk123 at hotmail.com> > >> > > Take a look at the .mc intermediate code output if you want to see> > > that section of the data. There are at least comments. Use m3cgcat -> > > binary < x.mc > x.mo to view it (You can run m3cgcat on any other > > CM3> > > install).> > >> > > On Jan 19, 2008, at 6:02 AM, Jay wrote:> > >> > > > Any chance the m3cg output could have, um, some symbols for the> > > > global data?> > > > It's kind of a pain to decode..> > > >> > > > The module/import info is ok a lot, lots of runtime links ok.> > > > I think the bad one might be RTHeapInfo but I have to decode the> > > > very bare of symbols assembly..> > > > or comments? Like for record fields?> > > > Still thinking of sticking a call out to C code...Even> > > > OutputDebugString since RTIO isn't working...> > > >> > > > I looked through the m3cg --help, didn't find anything.> > > >> > > > Tony?> > > >> > > > _MM_RTHeapInfo:> > > > 0 .long _L_1+224> > > > 4 .long _MM_RTHeapInfo+52> > > > 8 .long _MM_RTHeapInfo+308> > > > 12,16 .space 8> > > > 20 .long _L_1+152> > > > 24 .space 4> > > > 28 .long _L_1+220> > > > 32 .long _L_1+220> > > > 36 .long _MM_RTHeapInfo+160> > > > 40 .space 4> > > > .long _RTHeapInfo_M3> > > >> > > > I get to count out to 160 bytes from here..:> > > >> > > > _L_1:> > > > 0 .byte 48> > > > 1 .byte 49> > > > 2 .byte 50> > > > 3 .byte 51> > > > 4 .byte 52> > > > 5 .byte 53> > > > 6 .byte 54> > > > 7 .byte 55> > > > 8 .byte 56> > > > 9 .byte 57> > > > a .byte 97> > > > b .byte 98> > > > c .byte 99> > > > d .byte 100> > > > e .byte 101> > > > f .byte 102> > > > 10 .long _RTHooks__TextLitInfo> > > > 14 .long _RTHooks__TextLitGetChar> > > > 18 .long _RTHooks__TextLitGetWideChar> > > > 1c .long _RTHooks__TextLitGetChars> > > > 20 .long _RTHooks__TextLitGetWideChars> > > > 24 .long 2> > > > 28 .long _L_1+16> > > > 2c .long 7> > > > 30 .ascii "shownew"> > > > 37 .space 1> > > > 38 .long 2> > > > 3c .long _L_1+16> > > > 40 .long 6> > > > 44 .ascii "update"> > > > 4a .space 2> > > > 4c .ascii "RTHeapInfo_M3"> > > > 50 .space 1> > > > .ascii "Init"> > > > .space 1> > > >> > > > I'll try the C code..> > > >> > > > - Jay> > > >> > > >> > > >> > > >> > > >> > > > Connect and share in new ways with Windows Live. Get it now!> > >> >> >> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.> 

Climb to the top of the charts! Play the word scramble challenge with star power. Play now! 
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080120/2bd01ce9/attachment-0002.html>


More information about the M3devel mailing list