Assembler files and C in GCC / bartman's amiga-debug

[zero]

I'm using bartman's amiga-debug VScode extension and I want to include some assembler files in my project.

I tried to modify the makefile like this:

s_sources := $(wildcard *.s) $(wildcard $(addsuffix *.s,$(subdirs)))
s_objects := $(addprefix obj/,$(patsubst %.s,%.o,$(notdir $(s_sources))))
objects := $(cpp_objects) $(c_objects) $(s_objects)

...

$(s_objects): obj/%.o : %.s
	$(info Assembling $<)
	@$(CC) $(CCFLAGS) $(ASFLAGS) -xassembler-with-cpp -c -o $@ $(CURDIR)/$<

I commented out the rule for support/gcc8_a_support.s, but I get these errors on building:

Compiling main.c
Compiling support/gcc8_c_support.c
Assembling vfill.s
Assembling support/gcc8_a_support.s
Linking a.mingw.elf
c:/users/zero/.vscode/extensions/bartmanabyss.amiga-debug-1.0.0/bin/opt/bin/../lib/gcc/m68k-amiga-elf/10.1.0/../../../../m68k-amiga-elf/bin/ld.exe: obj/gcc8_a_support.o: in function `__mulsi3':
D:/Amiga/code/test1/support/gcc8_a_support.s:40: multiple definition of `__mulsi3'; obj/gcc8_a_support.o:D:/Amiga/code/test1/support/gcc8_a_support.s:40: first defined here
c:/users/zero/.vscode/extensions/bartmanabyss.amiga-debug-1.0.0/bin/opt/bin/../lib/gcc/m68k-amiga-elf/10.1.0/../../../../m68k-amiga-elf/bin/ld.exe: obj/gcc8_a_support.o: in function `__udivsi3':
D:/Amiga/code/test1/support/gcc8_a_support.s:59: multiple definition of `__udivsi3'; obj/gcc8_a_support.o:D:/Amiga/code/test1/support/gcc8_a_support.s:59: first defined here
c:/users/zero/.vscode/extensions/bartmanabyss.amiga-debug-1.0.0/bin/opt/bin/../lib/gcc/m68k-amiga-elf/10.1.0/../../../../m68k-amiga-elf/bin/ld.exe: obj/gcc8_a_support.o: in function `__divsi3':
D:/Amiga/code/test1/support/gcc8_a_support.s:112: multiple definition of `__divsi3'; obj/gcc8_a_support.o:D:/Amiga/code/test1/support/gcc8_a_support.s:112: first defined here
c:/users/zero/.vscode/extensions/bartmanabyss.amiga-debug-1.0.0/bin/opt/bin/../lib/gcc/m68k-amiga-elf/10.1.0/../../../../m68k-amiga-elf/bin/ld.exe: obj/gcc8_a_support.o: in function `__modsi3':
...

There are a few more after that. Any idea what is going on here?

[Samurai_Crow]

It can't decide to cross compile to the Amiga or compile with Windows native linker files, it looks like to me.

[Ernst Blofeld]

Have you definitely done a clean after modifying your makefile? There aren't any left over .o files anywhere?

When I wanted to add assembly files to my project I found that the gcc assembler was just not useable. I used vasm instead and named the files I wanted it to assemble with a different suffix so that I could create a separate process within the makefile for them. Then you're free to do what you want without breaking any existing stuff.

Edit: I see you need -xassembler-with-cpp. My solution won't work for you if this is the case, unless you can break that into a separate step.

Edit 2: How do you stop it from trying to assemble the generated a.mingw.s file? Also, are you on the latest preview version of the vscode extension?

Edit 3: This works for me, apart from that pesky a.mingw.s, using the latest preview extension. I've added a test.s file with one test function included. Not an exhaustive test, but no errors. I would still recommend adding in vasm instead though.

# to generate assembler listing with LTO, add to LDFLAGS: -Wa,-adhln=$@.listing,--listing-rhs-width=200
# for better annotations add -dA -dP
# to generate assembler source with LTO, add to LDFLAGS: -save-temps=cwd

forward-to-backward = $(subst /,\,$1)

subdirs := $(wildcard */)
VPATH = $(subdirs)
cpp_sources := $(wildcard *.cpp) $(wildcard $(addsuffix *.cpp,$(subdirs)))
cpp_objects := $(addprefix obj/,$(patsubst %.cpp,%.o,$(notdir $(cpp_sources))))
c_sources := $(wildcard *.c) $(wildcard $(addsuffix *.c,$(subdirs)))
c_objects := $(addprefix obj/,$(patsubst %.c,%.o,$(notdir $(c_sources))))
s_sources := $(wildcard *.s) $(wildcard $(addsuffix *.s,$(subdirs)))
s_objects := $(addprefix obj/,$(patsubst %.s,%.o,$(notdir $(s_sources))))
objects := $(cpp_objects) $(c_objects) $(s_objects)

# https://stackoverflow.com/questions/4036191/sources-from-subdirectories-in-makefile/4038459
# http://www.microhowto.info/howto/automatically_generate_makefile_dependencies.html

OUT = a.mingw
CC = m68k-amiga-elf-gcc

CCFLAGS = -g -MP -MMD -m68000 -Ofast -nostdlib -Wextra -Wno-unused-function -Wno-volatile-register-var -fomit-frame-pointer -fno-tree-loop-distribution -flto -fwhole-program -fno-exceptions
ASFLAGS = -Wa,-g,--register-prefix-optional
LDFLAGS = -Wl,--emit-relocs,-Ttext=0,-Map=$(OUT).map

all: $(OUT).exe

$(OUT).exe: $(OUT).elf
	$(info Elf2Hunk $(OUT).exe)
	@elf2hunk $(OUT).elf $(OUT).exe

$(OUT).elf: $(objects)
	$(info Linking a.mingw.elf)
	@$(CC) $(CCFLAGS) $(LDFLAGS) $(objects) -o $@
	@m68k-amiga-elf-objdump --disassemble --no-show-raw-ins --visualize-jumps -S $@ >$(OUT).s 

clean:
	$(info Cleaning...)
	@del /q obj $(OUT).* 2>nul || rmdir obj 2>nul || ver>nul

-include $(objects:.o=.d)

$(cpp_objects) : obj/%.o : %.cpp
	@if not exist "$(call forward-to-backward,$(dir $@))" mkdir $(call forward-to-backward,$(dir $@))
	$(info Compiling $<)
	@$(CC) $(CCFLAGS) -c -o $@ $(CURDIR)/$<

$(c_objects) : obj/%.o : %.c
	@if not exist "$(call forward-to-backward,$(dir $@))" mkdir $(call forward-to-backward,$(dir $@))
	$(info Compiling $<)
	@$(CC) $(CCFLAGS) -c -o $@ $(CURDIR)/$<

$(s_objects): obj/%.o : %.s
	$(info Assembling $<)
	@$(CC) $(CCFLAGS) $(ASFLAGS) -c -o $@ $(CURDIR)/$<

Edit 4: changing the m68k-amiga-elf-objdump line that creates a.mingw.s to create a .txt file instead doesn't seem to break anything.

[zero]

Thanks Ernst, that fixed it!

I hate makefiles, not because they are terrible but because I only do them occasionally and always forget how to debug them in-between.

[Jobbo]

I wanted to do the same thing and compile any .s file I added to the project. I don't really know how all the makefile voodoo works but was able to come up with this solution that avoids renaming the output .s file.

s_sources := $(subst $(OUT).s,,$(wildcard *.s) $(wildcard $(addsuffix *.s,$(subdirs))))

You also need to move OUT up before this line.

[Ernst Blofeld]

Originally Posted by Jobbo

I wanted to do the same thing and compile any .s file I added to the project. I don't really know how all the makefile voodoo works but was able to come up with this solution that avoids renaming the output .s file.

s_sources := $(subst $(OUT).s,,$(wildcard *.s) $(wildcard $(addsuffix *.s,$(subdirs))))

You also need to move OUT up before this line.

Using the gnu assembler? How's that working out for you?

[Jobbo]

Not good! I wasn’t expecting it to be so different.

Not sure if it’s worth pushing on with or getting vasm going.

What’s been you experience with that?

[Ernst Blofeld]

Originally Posted by Jobbo

Not good! I wasn’t expecting it to be so different.

Not sure if it’s worth pushing on with or getting vasm going.

What’s been you experience with that?

vasm has been totally faultless. -Felf to make it fall in line with the rest of the build process and it just works.

[zero]

I haven't used vasm, and only done a tiny bit of 68k in the GNU assembler. I've done a lot of AVR asm in the GNU assembler though and it's been fine... What is the advantage of vasm?

[Ernst Blofeld]

Originally Posted by zero

I haven't used vasm, and only done a tiny bit of 68k in the GNU assembler. I've done a lot of AVR asm in the GNU assembler though and it's been fine... What is the advantage of vasm?

For me, just that it supports the syntax that I still remember from the first time round. gas supports a different standard. It can be somewhat flexible about it, and it's your only choice for inline stuff, but it's not the same experience.

[Jobbo]

I've done lots of inline asm and that is relatively nice. You do have to learn the rules for specifying registers and clobbers and all that but it's manageable.

Where it breaks down for me is when your inline asm is pushing the limit of how many registers there are. It seems I can write code that uses them all and it'll compile fine sometimes but in a different context, maybe because other code changed, it'll fail. Mostly seems to be the optimizer running into trouble.

So, I had a quick look at adding .s files and immediately ran into unfamiliar syntax, even compared to the inline stuff. Maybe it's worth learning all that, but on the other hand if I want to integrate code from other places for a mod player or whatever it'll all need ported to the new syntax.

What's not clear to me is if there is a downside using vasm. We should probably ask Bartman on Github what he thinks.

Btw. What is this: -x assembler-with-cpp option? I can't find any documentation for that anywhere.

[zero]

Originally Posted by Jobbo

Btw. What is this: -x assembler-with-cpp option? I can't find any documentation for that anywhere.

It just makes it run the C preprocessor over the .s file before compiling it, so you can use C preprocessor directives like #define and #if.

I am only just getting back into 68k assembler and never used it with C before, but on other platforms like AVR and ARM even with inline you have to observe some rules for register preservation. For example on AVR you must clear r1, the complied always expects it to be zero even if you said you clobbered it.

I wish the inline syntax was a bit better, it's just annoying and awkward.