VLINK / VBCC / VASM linking order issue

[adrianpbrown]

Hi, Ive setup a build system that uses vasm to assemble files, vc/vbcc to compile files and vlink to link them all in amiga hunk format. Im not including the startup.o / mstartup.o as i dont want to use the C code as the initial startup. I pass one of the asm->.o files as the first object code to the linker but still it insists on putting the .c->.o file as the startup even though it is literally just this

int SomeFunction()
{
int i = 10;
i++;
return i;
}

(Its just a test function for now). Everything suggests that amiga linking should use the first .o as the entry point? Am I doing something wrong? Also i couldnt find the source code to the startup.o/mstartup.o files so i cant alter these to my requirements either

Many Thanks

[phx]

Originally Posted by adrianpbrown

Everything suggests that amiga linking should use the first .o as the entry point?

Correct. An Amiga executable is always started with the first instruction in the first section. A linker usually keeps the order of object files on the command line, when merging their sections into the output executable.

Am I doing something wrong?

Probably. But hard see without an example, like the full commandline when calling vlink. Hint: You may call vlink with the -M option, which generates a map file. It shows the order of all files and sections in the output.

Also i couldnt find the source code to the startup.o/mstartup.o files so i cant alter these to my requirements either

vclib is free, but not open source. Anything special you would need?

[adrianpbrown]

Ahh, that starts to throw more information onto the issue

Assembling:     System.asm
l:\catfish\amiga\rubyfire\tools\bin\vasmm68k_mot.exe -m68000 -Fhunk -linedebug -spaces -phxass -opt-fconst -nowarn=62 -I"../Includes" -I"Includes" -I"Libs/Catfish/Includes" -o "Libs/Catfish/Build/System.o" Libs/Catfish/Src/System.asm
Compiling:      System.c
l:\catfish\amiga\rubyfire\tools\bin\vc.exe +aos68k_win -g -c -I"../../tools/bin/targets/m68k-amigaos/include" -I"../Includes" -I"Includes" -I"Libs/Catfish/Includes" -o "Libs/Catfish/Build/System_c.o" Libs/Catfish/Src/System.c
Assembling:     main.asm
l:\catfish\amiga\rubyfire\tools\bin\vasmm68k_mot.exe -m68000 -Fhunk -linedebug -spaces -phxass -opt-fconst -nowarn=62 -I"../Includes" -I"Includes" -I"Libs/Catfish/Includes" -o "Build/main.o" Src/main.asm
Linking:        blah.exe
l:\catfish\amiga\rubyfire\tools\bin\vlink -bamigahunk -x -Bstatic -Cvbcc -nostdlib -M "Build/main.o" "Libs/Catfish/Build/System.o" "Libs/Catfish/Build/System_c.o" -L"../../tools/bin/targets/m68k-amigaos/lib" -lvc -o blah.exe

Files:
  main.asm:  GameCode 0(38), Variables 0(18) hex
  System.asm:  Framework 0(dc), Variables 0(3c) hex
  Libs\Catfish\Src\System.c:  CODE 0(8) hex


Section mapping (numbers in hex):
------------------------------
  00000000 GameCode  (size 38)
           00000000 - 00000038 main.asm(GameCode)
------------------------------
  00000000 Framework  (size dc)
           00000000 - 000000dc System.asm(Framework)
------------------------------
  00000000 CODE  (size 8)
           00000000 - 00000008 Libs\Catfish\Src\System.c(CODE)
------------------------------
  00000000 Variables  (size 3c)
           00000000 - 0000003c System.asm(Variables)
------------------------------
  00000000 Variables  (size 18, allocated 0)
           00000000 - 00000018 main.asm(Variables)


Symbols of GameCode:
  Startup: local reloc, value 0x0, size 0

Symbols of Framework:
  SYS_Takeover: global reloc, value 0x0, size 0
  _SYS_ReleaseWBMessage: local reloc, value 0x6a, size 0
  SYS_DisplayGUIMessage: local reloc, value 0x30, size 0
  _SYS_AllocMemory: local reloc, value 0x86, size 0
  SYS_Release: global reloc, value 0x2a, size 0
  _SYS_GetWBMessage: local reloc, value 0x32, size 0

Symbols of CODE:
  l1: local reloc, value 0x4, size 0
  _SomeFunction: global reloc, value 0x0, size 0

Symbols of Variables:
  _SYSERROR_UnableAllocChip: local reloc, value 0x0, size 0
  _SYSERROR_UnableAllocFast: local reloc, value 0x1e, size 0

Symbols of Variables:
  SYS_Details: local reloc, value 0x0, size 0

It looks like it doesnt recognise the section details of the .asm file as code (Although that could just be the actual name).

The start of the main.asm is

							SECTION		GameCode, CODE_F

Startup:
							jsr			_SomeFunction

As to the startup file, hard to say other than i like to know exactly whats going on. Im not too fussed about using the standard libraries, its more just using C for functions to try and speed up development a bit (although most will likely be in asm).

Cheers

[phx]

Originally Posted by adrianpbrown

l:\catfish\amiga\rubyfire\tools\bin\vlink -bamigahunk -x -Bstatic -Cvbcc -nostdlib -M "Build/main.o" "Libs/Catfish/Build/System.o" "Libs/Catfish/Build/System_c.o" -L"../../tools/bin/targets/m68k-amigaos/lib" -lvc -o blah.exe

Files:
  main.asm:  GameCode 0(38), Variables 0(18) hex
  System.asm:  Framework 0(dc), Variables 0(3c) hex
  Libs\Catfish\Src\System.c:  CODE 0(8) hex

Your code has no reference to vclib at all. Otherwise you would read on top of the map file something like "vclib (path/file.c) needed due to _xyz". So you could also choose to drop -L.. and -lvc at this point.

Section mapping (numbers in hex):
------------------------------
  00000000 GameCode  (size 38)
           00000000 - 00000038 main.asm(GameCode)

Looking good. This is your first section in the executable, so the first instruction from main.asm(GameCode) starts it.

It looks like it doesnt recognise the section details of the .asm file as code (Although that could just be the actual name).

It's just the section name. The C-compiler calls the code-section "CODE", while you called it "GameCode" and "Framework".

Note, that the linker will not merge sections with different names and/or types (unless specifying the -sc option to merge all code, or -sd to merge all data/bss). This might be important if you want to use PC-relative references between your code parts.

The start of the main.asm is

                            SECTION        GameCode, CODE_F

Startup:
                            jsr            _SomeFunction

As to the startup file, hard to say other than i like to know exactly whats going on.

Is this not the first instructon executed in your executable? It should, according to the map file. I'm not sure whether I understand what your actual problem is.

(Side note: There is never a reason to use code_f instead of code, except you don't want anybody to run your code on a Chip-RAM-only system.)

Originally Posted by adrianpbrown

I pass one of the asm->.o files as the first object code to the linker but still it insists on putting the .c->.o file as the startup

What is a ".c->.o" file? Did you mean that System_c.o is the first code in your executable? I cannot believe that.

Im not too fussed about using the standard libraries, its more just using C for functions to try and speed up development a bit (although most will likely be in asm).

This should work fine.

[sparhawk]

Originally Posted by adrianpbrown

As to the startup file, hard to say other than i like to know exactly whats going on. Im not too fussed about using the standard libraries, its more just using C for functions to try and speed up development a bit (although most will likely be in asm).

If you plan to call C functions from your asm code, you may still need to write a regular "main()" module as your entrypoint and call your asm from there, as the compiler startup does some additional stuff in the background before it calls main, like initializing static variables etc..

[phx]

Originally Posted by sparhawk

If you plan to call C functions from your asm code, you may still need to write a regular "main()" module as your entrypoint

To be more precise: if you plan to call clib (vclib in this case) functions...

Initialising the clib, or running constructors, would be the main reason for a startup code. And not even all clib functions would need it. The string functions or ctype could still be used.

[adrianpbrown]

Thanks everyone. Ive sorted my issues, mostly it was a case of red herring where the debugger wasnt stopping on the breakpoint so it looked like it wasnt doing what it was supposed to.