Ok, got it almost to work.
The fbc exe now runs, inits ncurses (in fb_Init()) but then crashes; I know why, it still lacks proper libc initialization; I've found out when using libc from a linux assembly program (like fbc does, or, actually, rtlib does, which is staticly linked to fbc), you need to link against crt1.o, crti.o and crtn.o, which deal with libc initialization and deinitialization. Only problem is these set the "_start" symbol, plus they assume the user program entry point to be the "main" symbol. Not much of a problem but I'll need to further modify the fbc sources to deal with this... V1ctor, I hope you don't modify your local copy too much!
Or at least wait for a big fbc and rtlib patch coming from me...
Now I'm in a hurry, but I hope to get the port to work by tomorrow. Cross your fingers...
Cool ;)
Yeah, i thought about the crt initialization 'cause malloc() and such, it's not needed in Windows as crtdll will be initialized automagically, ow
My local copy atm is the same as the CVS one, i can add you as a member now at SF if you want - nick as "lillo" too in sf.net? You will have to handle the CVS conflicts tho ;).
I won't probably be able to do any updates this week, i can't really code atm, anywayz..
That would be nice and kind of you.
Yes, my SF user name is "lillo" too. No problems with CVS copy conflicts, I'm used to this stuff... It'll take little to get my copy in sync.
hm... seems like the problem isn't libc initialization after all; gdb reports segmentation fault on a call to strlen(). At first I thought this had to do with libc init, but now I'm linking the crt stuff in and properly initializing libc, and the problem persists. Here's what gdb reports:
Code:
Program received signal SIGSEGV, Segmentation fault.
0x40097a23 in strlen () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0x40097a23 in strlen () from /lib/tls/i686/cmov/libc.so.6
#1 0x0808489e in fb_StrCompare ()
#2 0x0804ae35 in L__T015E ()
#3 0x080ab140 in tmpdsList ()
#4 0xffffffff in ?? ()
#5 0x000003c8 in ?? ()
#6 0x00000001 in ?? ()
#7 0x00000001 in ?? ()
#8 0xbffff9b4 in ?? ()
#9 0x4014fedc in ?? () from /lib/tls/i686/cmov/libc.so.6
#10 0x00000000 in ?? ()
#11 0x00000000 in ?? ()
#12 0x00000000 in ?? ()
#13 0x00000000 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x00000000 in ?? ()
#17 0xbffff920 in ?? ()
#18 0x08049516 in __T000A ()
#19 0xbffff9bc in ?? ()
#20 0x080494da in fb_fbc_entry ()
#21 0x08081001 in main ()
And here's the asm listing:
Code:
L__T015E:
L__T015D:
# end if
#
# if( left$( argv(i), 1 ) = "-" ) then
# select case lcase$( mid$( argv(i), 2, 1 ) )
# '' source files
# case "b"
push 1
lea eax, [_t00e3]
push eax
push -1
push 1
mov eax, dword ptr [ebp -8]
lea ecx, [_ARGV + eax*8]
push ecx
call fb_LEFT
add esp, 8
push eax
call fb_StrCompare
add esp, 16
fb_StrCompare actually calls strlen just in FB_STRSETUP... Maybe there's a bug in the temp strings handling? Linux is much more strict than Windows when it comes to memory handling, so maybe a bad memory access is passed on Win32 and fails under Linux.
Will have to investigate this further...
discovered the problem may be somewhat harder than I thought... I've made a small compiling test, here's the listing:
Code:
#print "prova"
push 1
push 5
lea eax, [_t0009]
push eax
call fb_StrAllocTempDesc
add esp, 8
push eax
push 0
call fb_PrintString
add esp, 12
It prints (null) and segfaults; by inserting a debug printf() call in fb_strAllocTempDesc in RTlib, I found out this last function actually receives NULL as str parameter, even though the asm listing seems right... Dunno what's going wrong here, but I'm starting to fear I'll have to smash my head on the wall for another day or two before the port will be working... :roll:
Sorry for not reporting here anymore... Anyway, the port has been fully working for over a week now
Have a look at this screenshot (don't care about reported system date/time, it's under VirtualPC so the clock is screwed):
http://www.ecplusplus.com/images/fbc_linux2.jpg
There are no more problems; I'm just waiting for V1ctor for an official release... He has disappeared lately due to being a bit sick, but he's recovering.
Dude...1 week?
And you tell us now?
And are you Angelo from DQB?
And how come you haven't released some preview version?
And why the hell am I so hyper?
Quote:Dude...1 week?
Yes, about one week...
Quote:And you tell us now?
My intention was to have a new official version supporting Linux by X'mas, and by that time the port was already working... Too bad V1ctor got a bit sick and has been away lately, so you got no release. He's recovering though. I wanted to make a surprise, but at this point it makes no sense anymore to hide the working port...
Quote:And are you Angelo from DQB?
Yes it's me.
Quote:And how come you haven't released some preview version?
See above :wink:
Quote:And why the hell am I so hyper?
Maybe because you're a Linux user?
it's a fake i know it
nah, seriously great work dude good stuff