GCC 6.2 toolchain for AmigaOS 3

[arcanist]

I'm running into a problem using ReAction with gcc's libstubs.a.

It contains stubs generated from the 3.9 NDK SFDs like this:
void* LayoutBase[2] = { 0, "layout.library" };

These are used by newlib __initlibraries to auto-open the library if the program references the corresponding symbol.

However the names do not match ReAction class names. LayoutBase's name is "gadgets/layout.gadget" in the Autodoc. The program consequently fails the OpenLibrary call during newlib init and terminates.

(Interestingly the 3.2 NDK dropped these SFDs. Perhaps 3.9 had libraries named like this?)

Is it possible to skip auto-open, or to not link libstubs.a, without writing custom startup code?

[pipper]

AFAIK, if you define and initialize your own base pointer, the linker will not generate auto-open code for this library.

[arcanist]

Originally Posted by pipper

AFAIK, if you define and initialize your own base pointer, the linker will not generate auto-open code for this library.

That's how I thought it should work, too, but it doesn't appear to.

#include <proto/exec.h>
#include <proto/layout.h>

struct Library* LayoutBase;

int main() {
        LayoutBase = OpenLibrary("gadgets/layout.gadget", 0);
}

m68k-amigaos-gcc test.c

SnoopDOS shows a failed OpenLibrary for "layout.library" and the program terminates before reaching main.

[Samurai_Crow]

Have you tried giving a full assign path to the gadgets directory? Like "libs:gadgets/layout.gadget"? It may be confused by your relative path.

[bebbo]

Originally Posted by arcanist

That's how I thought it should work, too, but it doesn't appear to.

#include <proto/exec.h>
#include <proto/layout.h>

struct Library* LayoutBase;

int main() {
        LayoutBase = OpenLibrary("gadgets/layout.gadget", 0);
}

m68k-amigaos-gcc test.c

SnoopDOS shows a failed OpenLibrary for "layout.library" and the program terminates before reaching main.

Initialization means:

 struct Library* LayoutBase = NULL;

otherwise it's only a declaration.

PS: I removed auto opening for layout.library - there is non in AmigaOS 1/2/3

[arcanist]

Originally Posted by bebbo

Initialization means:

 struct Library* LayoutBase = NULL;

otherwise it's only a declaration.

PS: I removed auto opening for layout.library - there is non in AmigaOS 1/2/3

D'oh! That fixed it.

I was relying on BSS to initialize this to zero but there's clearly a difference explicitly initializing in the data segment.

[bebbo]

just to inform you: I changed the ABI: with fpu fp values are now returned in fp0.

[BSzili]

This is a dumb question, but does this mean I have to rebuild code (e.g. static libraries) that have functions returning floating point values?

[bebbo]

Originally Posted by BSzili

This is a dumb question, but does this mean I have to rebuild code (e.g. static libraries) that have functions returning floating point values?

yes sir, you have to. that's why I posted that info.

EDIT: the gain in combination with -Ofast or using -ffast-math is worth it.

[alkis]

that makes any difference if you have -m68881 as a compiler flag, right?

[bebbo]

Originally Posted by alkis

that makes any difference if you have -m68881 as a compiler flag, right?

to use floating point registers you need to specify -m68881 or -m68040 or -m68060 or -m68080


the fast math flag lets the compiler make some assumptions which speed it up. A good explanation is here: https://stackoverflow.com/questions/...th-actually-do

[BSzili]

Originally Posted by bebbo

yes sir, you have to. that's why I posted that info.

EDIT: the gain in combination with -Ofast or using -ffast-math is worth it.

Thanks, I just wanted to make sure I got it right I bet it helps not having to pass things through D0.

[Wrangler]

Hi, I'm having trouble using ld from Bebbo's gcc 6 with the -r option. Whatever I try, I end up with the error:

m68k-amigaos-ld: final link failed: bad value

even with very simple examples eg the following:

This is m68kobj.c compiled with gcc -c to m68kobj.o (nonsense program, I know)

int main()
{
	int a, b, c;
	a = 6;
	b = 5;
	c = a + b;
	a = c / 2;
	return 4;
}

Even doing:

m68k-amigaos-ld -r -o outobj.o m68kobj.o

gives the "bad value" error.

What is the fix for this because this is doing my head in!

(I'm using cygwin fwiw)

[bebbo]

m68k-amigaos-ld -r -o outobj.o m68kobj.o

gives the "bad value" error.

What is the fix for this because this is doing my head in!

(I'm using cygwin fwiw)[/QUOTE]


-r is not supported

m68k-amigaos-ld -o outobj.o m68kobj.o

is working

[BSzili]

I updated to the latest version and made a clean build, but ran into an issue where the C++ destructors for global objects now cause illegal instruction crashes. It only seems to happen if there's a function call in the destructor. I created a minimal example that reproduces the issue. This is what I have in dest.cpp:

#include <unistd.h>

class Resource
{
public:
    Resource(void);
    ~Resource(void);
    int handle;
};

Resource::Resource(void)
{
    handle = -1;
}

Resource::~Resource(void)
{
    if (handle != -1)
    {
        close(handle);
    }
}

Resource gRes;

int main(void)
{
	return 0;
}

I build it with

m68k-amigaos-g++ -Wall -noixemul -m68060 -m68881 -fbbb=- -fno-peephole2 -fomit-frame-pointer -O2 -fno-strict-aliasing -fno-exceptions -fno-rtti -o dest dest.cpp

but building with

m68k-amigaos-g++ -noixemul -o dest dest.cpp

also reproduces the crash.
I replaced __initcpp and __exitcpp with my own Printf-loaded wrappers to verify that the crash happens in __exitcpp when it calls the first offending destructor. What could be the cause of this?

[pipper]

Best report it on GitHub. Bebbo is usually super responsive there.

[bebbo]

Originally Posted by BSzili

I updated to the latest version and made a clean build, but ran into an issue where the C++ destructors for global objects now cause illegal instruction crashes. It only seems to happen if there's a function call in the destructor. I created a minimal example that reproduces the issue. This is what I have in dest.cpp:

#include <unistd.h>

class Resource
{
public:
    Resource(void);
    ~Resource(void);
    int handle;
};

Resource::Resource(void)
{
    handle = -1;
}

Resource::~Resource(void)
{
    if (handle != -1)
    {
        close(handle);
    }
}

Resource gRes;

int main(void)
{
    return 0;
}

I build it with

m68k-amigaos-g++ -Wall -noixemul -m68060 -m68881 -fbbb=- -fno-peephole2 -fomit-frame-pointer -O2 -fno-strict-aliasing -fno-exceptions -fno-rtti -o dest dest.cpp

but building with

m68k-amigaos-g++ -noixemul -o dest dest.cpp

also reproduces the crash.
I replaced __initcpp and __exitcpp with my own Printf-loaded wrappers to verify that the crash happens in __exitcpp when it calls the first offending destructor. What could be the cause of this?

ah - oow - DTORs are handled via mystic .stab entries which are assumed to be in specific sections. Since I started to support sections per functions, these ended up in a separate section and were not relocated



--> DTORs are now put into .text again.

[BSzili]

Thanks! If I build the executable with the longer command it works now, but

m68k-amigaos-g++ -noixemul -o dest dest.cpp

still produces crashing code. Could you check if you have the same issue?

[bebbo]

Originally Posted by BSzili

Thanks! If I build the executable with the longer command it works now, but

m68k-amigaos-g++ -noixemul -o dest dest.cpp

still produces crashing code. Could you check if you have the same issue?

it's now also fixed - as any other ctor/dtor should be working again

[BSzili]

Super, now all the destructors in Blood work again! The small example still crashes if I build it with the

m68k-amigaos-g++ -noixemul -o dest dest.cpp

command, but that's probably a different issue altogether.
I think I also ran into this inline assembly issue, but I'll try to make a minimal example to reproduce it.