GCC 6.2 toolchain for AmigaOS 3

[JuanLuis]

Originally Posted by jotd

can you show your build script (makefile/shell file?)

I have tried following options:

Assembler: gas -statistics -a --error-unresolved-symbols main.s
Linker: without options

Trying to pass --error-unresolved-symbols to linker:

Assembler: gas -statistics -a main.s
Linker: ld -Wl,--error-unresolved-symbols

In both cases --error-unresolved-symbols option is not recognized. GAS man says that this option should produce an error instead of a warning message.

By the way, you can see all the executed commands in build_msg.txt attached file.

[thyslo]

As this toolchain meanwhile produces really dense and fast code, and coding in Linux with VSCode is more fun than I wanted to admit, the next logical step for me would be to start a debugging session directly from VSCode. But I don’t know if this possible, yet.

I’m thinking of

• On debug start FS-UAE getting started
• FS-UAE starting a gdbserver with the created binary as target
• VSCode connects to this gdbserver
• VSCode can step trough the source code

So, has anybody here made some experiences with this so far?

[jotd]

I've used GnatProgrammingStudio with m68k-amigaos-gdb and WinUAE and debug works okay. Sometimes it doesn't find local variables, but it was very helpful when I developped my game, since display was completely taken by the game, so printing debug stuff was complicated...

Build & link with "-g" (and also "-noixemul" else you'll have issues/crashes with C lib). Link with "-Wl,--amiga-debug-hunk -ldebug"

Enable "bsdsocket.library" from "expansion" tab.

Startup sequence containing smth like

stack 30000
assign ENV: RAM:
bgdbserver name_of_your_exe

Boot and wait for segments to be loaded

now run a debug script (gdb)

file name_of_your_exe
target remote :2345

wait for gdb prompt. Now put breakpoints and continue.

[arti]

You could redirect debug from UAE with -serlog parameter and kprintf.
Then run name_of_your_exe > ser:.

[thyslo]

Thanks for your hints, I'll take them as a starting point when trying it with VSCode:-)

[bebbo]

Originally Posted by JuanLuis

I attach a couple of files. main.s is the assembler program with an error.

--- main.s ---
...
msg:
.ascii "Calculando numeros primos, espere por favor..."
dc.b LF
msg_end: /* msg_end is defined here */

msg_length = msg_ed - msg /* There is a mistake. It should be msg_end instead of msg_ed */
...

this will yield now

Error: invalid operands (*UND* and .text sections) for `-' when setting `msg_length'

should be live soon

[JuanLuis]

Originally Posted by bebbo

this will yield now

Error: invalid operands (*UND* and .text sections) for `-' when setting `msg_length'

should be live soon

Thanks Bebbo. Whatever type of error it's enough for me. If there isn't error for undefined symbols, I have to take a look on compiling results even if compilation is successful and this is annoying.

Will it be needed to specify "--error-unresolved-symbols" option to get that message in next gas / ld version? Where will it be the change, in linker?

[JuanLuis]

An additional error I have seen it's argv is broken. In GCC 6.5.0b argv[n] returns null string when argument n exists. That worked fine in GCC 6.4.0 but there is something broken in 6.5.0b with line arguments.

This problem is not important for me. Take it as a minor error report.

[alkis]

Originally Posted by JuanLuis

An additional error I have seen it's argv is broken. In GCC 6.5.0b argv[n] returns null string when argument n exists. That worked fine in GCC 6.4.0 but there is something broken in 6.5.0b with line arguments.

This problem is not important for me. Take it as a minor error report.

Umm, argument n is n-1 as C/C++ is zero indexed.

[alkis]

Originally Posted by JuanLuis

Will it be needed to specify "--error-unresolved-symbols" option to get that message in next gas / ld version? Where will it be the change, in linker?

Doesn't need any flags.

m68k-amigaos-gcc -o foo main.s
main.s: Assembler messages:
main.s: Error: invalid operands (*UND* and .text sections) for `-' when setting `msg_length'
alex[1]@debxvm test$ m68k-amigaos-as main.s
main.s: Assembler messages:
main.s: Error: invalid operands (*UND* and .text sections) for `-' when setting `msg_length'

[JuanLuis]

Ok, I'll do a git pull of gcc code.

Thanks.

[thyslo]

I had partial success with debugging in VSCode. I can set breakpoints and step through the code, but variables aren't displayed properly, yet.

E.g. an uninitialized member variable is pointing to something random, ok. Then there's a line of code where this variable is set to NULL. When I step over it still points to the same something random.

Then I re-read te thread post and found that I've missed an hint:

Originally Posted by jotd

Link with "-Wl,--amiga-debug-hunk -ldebug"

I added these options to the makefile. But after 'make debug' the created binary has the same size and content as before.

So I'm wondering if there's something wrong in the makefile:

# Setting up application name and directories
APPNAME=MyNewApp
APPNAME_DEBUG=MyNewApp_Debug

SRC_ROOT=src

OBJ_DIR=obj_release
OBJ_DIR_DEBUG=obj_debug

# Change some values for debug build
ifeq ($(BUILD),debug)
OBJ_DIR=$(OBJ_DIR_DEBUG)
APPNAME=$(APPNAME_DEBUG)
endif

# Specify the files and includes
DEPS=$(SRC_ROOT)/exampleclass.h

_OBJ=$(SRC_ROOT)/main.cpp \
                /exampleclass.cpp
 
INCLUDE=-I$(SRC_ROOT)

# Setting up compiler, flags and tools
CXX=/opt/amiga/bin/m68k-amigaos-c++
CXXFLAGS=-Wall -Wno-unused-function -fomit-frame-pointer -fno-rtti -fno-exceptions -noixemul
LD=/opt/amiga/bin/m68k-amigaos-ld
LDFLAGS=

ifeq ($(BUILD),debug)
# "Debug" build - no optimization, and debugging symbols
CXXFLAGS += -O0 -g -Wl,--amiga-debug-hunk -ldebug
#LDFLAGS += -Wl,--amiga-debug-hunk -ldebug
else
# "Release" build - optimization and no debug symbols
CXXFLAGS += -Os -s
endif

# Replace prefix SRC_ROOT with OBJ_DIR for object file target
OBJ=$(patsubst $(SRC_ROOT)/%,$(OBJ_DIR)/%,$(_OBJ))

# Building the .o files
# Note: the mkdir line creates the needed subdirectories in OB_DIR 
$(OBJ_DIR)/%.o: $(SRC_ROOT)/%.cpp $(DEPS)
	mkdir -p $(@D)
	$(CXX) $(CXXFLAGS) $(INCLUDE) -c -o $@ $< 


$(APPNAME): $(OBJ)
	$(CXX) $(CXXFLAGS) $(INCLUDE) -o $@ $^

release:
	make

debug:
	make "BUILD=debug"

# Cleaning build directory and executable
.PHONY: clean
clean:
	rm -rf $(OBJ_DIR) $(OBJ_DIR_DEBUG) $(APPNAME) $(APPNAME_DEBUG)

Anybody got an idea?

[JuanLuis]

Originally Posted by alkis

Umm, argument n is n-1 as C/C++ is zero indexed.

Alkis, I apologize for my poor explanation of the problem. I meant If you invoke the program with n arguments, main funciton sees these arguments argv[0] ... argv[n-1] as null. This worked fine in gcc 6.4.0, but it doesn't in gcc 6.5.0. Anyway there are other ways to pass arguments.

There are more important things like debugging. I prefer a comfortable debugging support than fixing minor issues.

Thanks for the answers.

[alkis]

#include <stdio.h>

int main(int argc, char *argv[])
{
  for(int i=0; i<argc; ++i)
    printf("Arg #%d -> \"%s\"\n", i, argv[i]);
  return 0;
}

this as args.cpp
compiled with
m68k-amigaos-g++ -mcrt=nix13 -Os -w -s args.cpp -o args

with this compiler
m68k-amigaos-g++ --version
m68k-amigaos-g++ (GCC) 6.5.0b 191023121710
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

produces an executable that runs correctly on (emulated) a500 & a1200
(i.e. argv[] is not null)

[jotd]

mcrt=nix13 is that kickstart 1.3 ? Is architecture 68000 by default?

I'd like to create a 68000-compatible executable, and why not for kickstart 1.3 too.

[alkis]

Originally Posted by jotd

mcrt=nix13 is that kickstart 1.3 ? Is architecture 68000 by default?

I'd like to create a 68000-compatible executable, and why not for kickstart 1.3 too.

Yes, mcrt=nix13 if for kickstart 1.3. By default is for 68000
You can further specify cpu with -m68020 -m68030 etc

[JuanLuis]

Originally Posted by alkis

#include <stdio.h>

int main(int argc, char *argv[])
{
  for(int i=0; i<argc; ++i)
    printf("Arg #%d -> \"%s\"\n", i, argv[i]);
  return 0;
}

this as args.cpp
compiled with
m68k-amigaos-g++ -mcrt=nix13 -Os -w -s args.cpp -o args

with this compiler
m68k-amigaos-g++ --version
m68k-amigaos-g++ (GCC) 6.5.0b 191023121710
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

produces an executable that runs correctly on (emulated) a500 & a1200
(i.e. argv[] is not null)

That program output following result (image is on the end of my post):
[IMG]ArgsTestOutput.jpg[/IMG]

The code was:

#include <stdio.h>

/*
 * 
 */
int main(int argc, char** argv) {
    for (int i = 0; i < argc; i++)
        printf("Arg #%d -> \"%s\"\n", i, argv[i]);
                
    return 0;
}

Compiler version (called Amiga_Cygwin64_Bebbo2-Windows in my Netbeans configuration):

m68k-amigaos-g++ (GCC) 6.5.0b 191023121710
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Building output:

cd 'C:\Users\Juan Luis\Documents\NetBeansProjects\ArgsTest'
D:\cygwin64\bin\make.exe -f Makefile CONF=Debug clean
"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .clean-conf
make[1]: se entra en el directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'
rm -f -r build/Debug
make[1]: se sale del directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'

CLEAN SUCCESSFUL (total time: 476ms)
cd 'C:\Users\Juan Luis\Documents\NetBeansProjects\ArgsTest'
D:\cygwin64\bin\make.exe -f Makefile CONF=Debug
"/usr/bin/make" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
make[1]: se entra en el directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'
"/usr/bin/make"  -f nbproject/Makefile-Debug.mk dist/Debug/Amiga_Cygwin64_Bebbo2-Windows/argstest.exe
make[2]: se entra en el directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'
mkdir -p build/Debug/Amiga_Cygwin64_Bebbo2-Windows
rm -f "build/Debug/Amiga_Cygwin64_Bebbo2-Windows/main.o.d"
m68k-amigaos-g++    -c -g -std=c++14 -MMD -MP -MF "build/Debug/Amiga_Cygwin64_Bebbo2-Windows/main.o.d" -o build/Debug/Amiga_Cygwin64_Bebbo2-Windows/main.o main.cpp
mkdir -p dist/Debug/Amiga_Cygwin64_Bebbo2-Windows
m68k-amigaos-g++     -o dist/Debug/Amiga_Cygwin64_Bebbo2-Windows/argstest build/Debug/Amiga_Cygwin64_Bebbo2-Windows/main.o 
make[2]: se sale del directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'
make[1]: se sale del directorio '/cygdrive/c/Users/Juan Luis/Documents/NetBeansProjects/ArgsTest'

BUILD SUCCESSFUL (total time: 1s)

- Must I link with any static library?
- Is there any problem on my gcc building?

[bebbo]

Originally Posted by JuanLuis

...
Building output:

...
m68k-amigaos-g++    -c -g -std=c++14 -MMD -MP -MF "build/Debug
...
m68k-amigaos-g++     -o dist/Debug/Amiga_Cygwin64_Bebbo2-Windows
...

- Must I link with any static library?

- Is there any problem on my gcc building?

you must use -noixemul or one of -mcrt=nix13, -mcrt=nix20, -mcrt=clib2


The default libraries are not that good... and you may create a ticket here: https://github.com/bebbo/newlib-cygwin/issues

[jotd]

I confirm that without -noixemul it just crashed without reason. But replacing -noixemul by -mcrt=nix13 works also very well. Also the amigaincludes are different and kick13 compatible (got an error with OpenWindowTags)

=> exactly what you need for legacy Amigas.

Thanks again bebbo for this great compiler. I couldn't have completed my game project without it.

[JuanLuis]

Originally Posted by bebbo

you must use -noixemul or one of -mcrt=nix13, -mcrt=nix20, -mcrt=clib2


The default libraries are not that good... and you may create a ticket here: https://github.com/bebbo/newlib-cygwin/issues

It works fine with -noixemul.

What option is better?

-noixemul or -mcrt ...?

Thanks for your help.