VBCC POSIX Library and 68020 Instructions

[tygre]

Hi all!

It's me again with yet-another question!

It happened that Leof wants to run AmiModRadio on a 68000-based Amiga but it crashes very, very early with a Guru 8000 0003. I used CubicIDE to generate a very simple "Hello World" program and compile it, modifying its makefile until it'd invoke the same Guru... and I did! The offending "line" is:

LD = vbcc:bin/vc -nostdlib -mrel VLibOS3:startup.o -LVBCC:targets/posixlib/lib/ -lposix -LVLibOS3: -lvc

With this line, the generated code works on a 68020 but Guru 8000 0003 on a 68000. If I move -LVBCC:targets/posixlib/lib/ -lposix after -lvc, then it runs on both 68000 and 68020. Could the VBCC POSIX library have some 68020-specific instructions? The ReadMe says that some math functions require a FPU, but they are not used at the startup of "Hello World"... or are they?

(Anyway, inverting -lposix and -lvc for AmiModRadio doesn't solve the problem for AmiModRadio like it does for "Hello World". )

Thanks in advance!

[meynaf]

Error 80000003 means Address Error. It has nothing to do with FPU or the 68020 instructions themselves.
Contrary to 68020, the 68000 can't access words and longwords at odd addresses and generates this error. Thus your problem is related to memory alignment. I don't know how to solve this issue on VBCC though.

[tygre]

Thanks Meynaf!

Maybe there'll be other suggestions!

[Don_Adan]

Originally Posted by tygre

Thanks Meynaf!

Maybe there'll be other suggestions!

Easy, dont use byte data, only word data and longword data. And all strings (with null) must have even length.

[tygre]

Thanks Don! But I don't see how that'd be (somewhat easily) possible... and that doesn't explain why the Guru happens before the main is even called...

[Don_Adan]

Originally Posted by tygre

Thanks Don! But I don't see how that'd be (somewhat easily) possible... and that doesn't explain why the Guru happens before the main is even called...

Then try to compile for 68000, if complicator is smart enough it can be enough. If problem occured before main routine is called then your init code is not compatible with 68000. You can show crash code from WHDload.

[tygre]

Thanks

I did try to explicitly set cpu=68000 but the exact same Guru was happening.

I'm now removing POSIX code from AmiModRadio, I wanted to do that anyway!

Cheers!

[alkis]

One thing I've noticed (and I don't have any experience with vbcc) is that you specify -mrel which might suggest base-relative code but you link with startup.o. Usually there are different startups depending if you go for relative code or not. I.e. I would expect to link with startuprel.o or something.

[tygre]

Thanks Alkis!

I don't know much about that either but AFAICS, VBCC provides only one file startup.o (no variants). Maybe it can work in both case?

[phx]

The vbcc_PosixLib from Aminet is compiled for 68020/68881! That should explain your problems, as soon as you link with it. Yes, the Readme is confusing (or plain wrong!). Will be fixed.

Theoretically you can try to compile most of it for 68000. Source is included. Change the third line of

Makefile.68k

to

COPTS = -c99 -O1 -Iinclude -DNO_INLINE_STDARG

.

-lposix must be linked before -lvc, because some clib functions will be overwritten by their extended POSIX version.

-mrel merges sections with relative references between them. It has nothing to do with base-relative addressing (small-data). Useful, when your section naming is a mess.

[tygre]

Hi Phx!

Thanks for your explanations, as usual!
Should I keep -mrel at all, then?

I actually removed all dependencies to POSIX (wanted to have "pure" Amiga code for a long time anyway) but still the Guru 8000 0003 comes. It happens, it seems, before my main() is even called... Do you have any suggestion where to dig?

Cheers!

[phx]

Originally Posted by tygre

Should I keep -mrel at all, then?

Remove it and see what happens. With all object files from vbcc there shouldn't be any difference.

I actually removed all dependencies to POSIX (wanted to have "pure" Amiga code for a long time anyway)

That's what I always recommend. Eliminate as many dependencies as possible and make it a real AmigaOS program.
POSIX emulation is for Q&D Unix ports only.

but still the Guru 8000 0003 comes. It happens, it seems, before my main() is even called...

Constructors are being called before

main()

. PosixLib certainly inserted some of these. But as you say it is gone... check your other constructors (functions named

__INIT..

). Or let the linker generate a mapfile to see which constructors have been found. Or debug the startup. Shouldn't be so difficult.

EDIT: BTW, I just realised you passed

-mrel

to the vc-frontend. That cannot work as this is a linker-option only.

[tygre]

Thanks Phx!

Actually, I was passing -mrel to vlink for AmiModRadio but not for the MWE... Now, I removed -mrel everywhere and everything works as before!

I generated a mapfile but... I don't understand it
I see some "init" things, for example at the very beginning:

VBCC:targets/m68k-amigaos/NDK_32/lib/vc.lib (_math.s) needed due to __math_init
VBCC:targets/m68k-amigaos/NDK_32/lib/vc.lib (_main.c) needed due to ___main
VBCC:targets/m68k-amigaos/NDK_32/lib/vc.lib (stdio/fopen.c) needed due to _fopen
...
INITEXIT:  .ctors 0(10), .dtors 0(14) hex
...
------------------------------
  00000000 .ctors  (size 10, allocated c)
           00000000 - 00000010 INITEXIT(.ctors)
...
  0x00006f94 __INIT_2_stdio: global reloc, size 0
...
  0x0000a534 __INIT_5_time: global reloc, size 0
...

but I don't know how I could use this... Sorry for being such a n00b!

[phx]

Ok. Size of

.ctors

is 16 bytes, which means four longwords. So you have two constructors. The vbcc constructor/destructor tables start with the number of pointers, followed by the function pointers (sorted by priority) and finally a NULL pointer.

You also found the two function names, which seem pretty standard vclib. The only other function called before

main()

is

__math_init

, which is a dummy until you link with

-lm881/040/060

. But this code would cause a Line-F exception and not an alignment exception.

At this point I would guess that there is something wrong with your build process. Please show in detail which options you use to call compiler and linker and what are your exact steps. You may also want to contact me by email, as I doubt that many people are interested in this specific problem.
To reproduce your problem I would need the executable, the object files and your final linker call to build the executable.

[tygre]

Thanks a lot Phx!

Here is the main code of my makefile:

CC     = vbccm68k -quiet -cpp-comments                     \
	 -DAMISSL_NO_STATIC_FUNCTIONS                      \
	 -IDevKits:sdk/classic/AmiSSL/Developer/include    \
	 -IDevKits:sdk/classic/ClassAct2/include_h/        \
	 -Idevkits:sdk/classic/MUI/Developer/C/Include/    \
	 -Idevkits:sdk/classic/NDK_32R4/Include_H/         \
	 -Idevkits:sdk/classic/Roadshow/netinclude/        \
	 -IDevKits:sdk/classic/XAD/Include/C/              \
	 -IVBCC:targets/m68k-amigaos/NDK_32/include/
AS     = vasmm68k_mot -quiet -Fhunk
LD     = vlink -bamigahunk -Cvbcc -Bstatic VLibOS3:startup.o
LDLIBS = -LVBCC:targets/m68k-amigaos/NDK_32/lib/ -lamiga   \
	 -LVLibOS3: -lvc

...

all :  COFLAGS += -O=1 -g -hunkdebug -DFORTIFY -DUNRECOGNISED
all :  ASFLAGS +=
all :  LDFLAGS += 
all :  $(EXEDIR)     \
	$(OBJECTSDIR) \
	$(EXE)        \
	catalogs      \
	data          \
	docs          \
	images

...

$(OBJECTS) : $(OBJECTSDIR)%.o : %.c
	$(CC) $(COFLAGS) $< -o=T:vbcc.asm
	$(AS) $(ASFLAGS) T:vbcc.asm -o $@
	rm T:vbcc.asm

$(EXE) : $(OBJECTS)
	$(LD) $(LDFLAGS) $(OBJECTS) $(LDLIBS) -o $(EXE)

Is there something wrong with these options/flags?

[coldacid]

OT, but tygre, you use Cubic IDE?

[tygre]

Hey ColdAcid!

Yes, CubicIDE is a great IDE
It works very well and integrates out-of-the-box VBCC (and others).

[phx]

Originally Posted by tygre

Is there something wrong with these options/flags?

I cannot spot a serious mistake at first sight. Is there a reason to call compiler, assembler and linker yourself, instead of using the

vc

frontend?

You mentioned CubicIDE. Which version of vbcc is that?

If you prefer not to send an example for reproduction your next step would be either to debug the startup or remove/uncomment code until the problem disappears.

[tygre]

Hi Phx!

Thanks for checking!

I was doing as you suggested: removing everything and adding it back little by little and I found the cause of the problem!

I use __stack to enforce a stack size:

size_t            __stack            = GLOBALS_TASK_STACK_SIZE;

with

#define GLOBALS_TASK_STACK_SIZE            65535

Frankly, I don't know why I chose 65535 but this odd number was the problem! After some experiments, it turns out that 65536 (any even number, really) allows AmiModRadio to run Now, AmiModRadio doesn't crash but it doesn't run because of some missing libraries, I'm going to test it fully...

Cheers!

[coldacid]

Out of box, the last version of Cubic IDE ships with vbcc 0.8j, but it's not that difficult to configure it with newer versions, especially if one is comfortable with s-expressions (it's simply a matter of adding a proper `compiler` expression int devkits:devkits.config). I have 0.9h installed and configured myself this way for Cubic.