15 June 2021, 02:36 | #1281 |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 409
|
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? |
15 June 2021, 03:01 | #1282 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 656
|
AFAIK, if you define and initialize your own base pointer, the linker will not generate auto-open code for this library.
|
15 June 2021, 04:01 | #1283 | |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 409
|
Quote:
Code:
#include <proto/exec.h> #include <proto/layout.h> struct Library* LayoutBase; int main() { LayoutBase = OpenLibrary("gadgets/layout.gadget", 0); } Code:
m68k-amigaos-gcc test.c |
|
15 June 2021, 05:47 | #1284 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,187
|
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.
|
15 June 2021, 06:05 | #1285 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 680
|
Quote:
Initialization means: Code:
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 Last edited by bebbo; 15 June 2021 at 07:21. |
|
15 June 2021, 15:27 | #1286 | |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 409
|
Quote:
I was relying on BSS to initialize this to zero but there's clearly a difference explicitly initializing in the data segment. |
|
20 September 2021, 09:47 | #1287 |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 680
|
just to inform you: I changed the ABI: with fpu fp values are now returned in fp0.
|
27 September 2021, 07:06 | #1288 |
old chunk of coal
Join Date: Nov 2011
Location: Hungary
Posts: 1,292
|
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?
|
27 September 2021, 09:30 | #1289 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 680
|
Quote:
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. |
|
27 September 2021, 12:42 | #1290 |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 719
|
that makes any difference if you have -m68881 as a compiler flag, right?
|
27 September 2021, 14:11 | #1291 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 680
|
Quote:
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 |
|
27 September 2021, 18:51 | #1292 |
old chunk of coal
Join Date: Nov 2011
Location: Hungary
Posts: 1,292
|
|
29 September 2021, 21:41 | #1293 |
Registered User
Join Date: Sep 2015
Location: London, UK
Posts: 414
|
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:
Code:
m68k-amigaos-ld: final link failed: bad value This is m68kobj.c compiled with gcc -c to m68kobj.o (nonsense program, I know) Code:
int main() { int a, b, c; a = 6; b = 5; c = a + b; a = c / 2; return 4; } Code:
m68k-amigaos-ld -r -o outobj.o m68kobj.o What is the fix for this because this is doing my head in! (I'm using cygwin fwiw) |
30 September 2021, 09:22 | #1294 |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 680
|
Code:
m68k-amigaos-ld -r -o outobj.o m68kobj.o What is the fix for this because this is doing my head in! (I'm using cygwin fwiw)[/QUOTE] -r is not supported Code:
m68k-amigaos-ld -o outobj.o m68kobj.o is working |
06 October 2021, 09:17 | #1295 |
old chunk of coal
Join Date: Nov 2011
Location: Hungary
Posts: 1,292
|
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:
Code:
#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; } m68k-amigaos-g++ -Wall -noixemul -m68060 -m68881 -fbbb=- -fno-peephole2 -fomit-frame-pointer -O2 -fno-strict-aliasing -fno-exceptions -fno-rtti -o dest dest.cppbut building with m68k-amigaos-g++ -noixemul -o dest dest.cppalso 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? |
06 October 2021, 10:10 | #1296 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 656
|
Best report it on GitHub. Bebbo is usually super responsive there.
|
07 October 2021, 12:14 | #1297 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 680
|
Quote:
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. |
|
07 October 2021, 18:08 | #1298 |
old chunk of coal
Join Date: Nov 2011
Location: Hungary
Posts: 1,292
|
Thanks! If I build the executable with the longer command it works now, but
m68k-amigaos-g++ -noixemul -o dest dest.cppstill produces crashing code. Could you check if you have the same issue? |
08 October 2021, 16:02 | #1299 |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 680
|
|
08 October 2021, 17:49 | #1300 |
old chunk of coal
Join Date: Nov 2011
Location: Hungary
Posts: 1,292
|
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.cppcommand, 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. |
Currently Active Users Viewing This Thread: 2 (0 members and 2 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
New GCC based dev toolchain for AmigaOS 3.x | cla | Coders. Releases | 8 | 24 December 2017 10:18 |
Issue with photon/xxxx WinUAE Toolchain | arpz | Coders. Asm / Hardware | 2 | 26 September 2015 22:33 |
New 68k gcc toolchain | arti | Coders. C/C++ | 17 | 31 July 2015 03:59 |
Hannibal's WinUAE Demo Toolchain 5 | Bobic | Amiga scene | 1 | 23 July 2015 21:04 |
From gcc to vbcc. | Cowcat | Coders. General | 9 | 06 June 2014 14:45 |
|
|