English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 15 June 2021, 02:36   #1281
arcanist
Registered User
 
Join Date: Dec 2017
Location: Austin, TX
Age: 38
Posts: 326
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?
arcanist is offline  
Old 15 June 2021, 03:01   #1282
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 326
AFAIK, if you define and initialize your own base pointer, the linker will not generate auto-open code for this library.
pipper is offline  
Old 15 June 2021, 04:01   #1283
arcanist
Registered User
 
Join Date: Dec 2017
Location: Austin, TX
Age: 38
Posts: 326
Quote:
Originally Posted by pipper View Post
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.

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
SnoopDOS shows a failed OpenLibrary for "layout.library" and the program terminates before reaching main.
arcanist is offline  
Old 15 June 2021, 05:47   #1284
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 47
Posts: 1,796
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.
Samurai_Crow is offline  
Old 15 June 2021, 06:05   #1285
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 556
Quote:
Originally Posted by arcanist View Post
That's how I thought it should work, too, but it doesn't appear to.

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
SnoopDOS shows a failed OpenLibrary for "layout.library" and the program terminates before reaching main.

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.
bebbo is offline  
Old 15 June 2021, 15:27   #1286
arcanist
Registered User
 
Join Date: Dec 2017
Location: Austin, TX
Age: 38
Posts: 326
Quote:
Originally Posted by bebbo View Post
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
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.
arcanist is offline  
Old 20 September 2021, 09:47   #1287
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 556
just to inform you: I changed the ABI: with fpu fp values are now returned in fp0.
bebbo is offline  
Old 27 September 2021, 07:06   #1288
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 555
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?
BSzili is offline  
Old 27 September 2021, 09:30   #1289
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 556
Quote:
Originally Posted by BSzili View Post
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.
bebbo is offline  
Old 27 September 2021, 12:42   #1290
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 50
Posts: 649
that makes any difference if you have -m68881 as a compiler flag, right?
alkis is offline  
Old 27 September 2021, 14:11   #1291
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 556
Quote:
Originally Posted by alkis View Post
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
bebbo is offline  
Old 27 September 2021, 18:51   #1292
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 555
Quote:
Originally Posted by bebbo View Post
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.
BSzili is offline  
Old 29 September 2021, 21:41   #1293
Wrangler
Registered User

 
Join Date: Sep 2015
Location: London, UK
Posts: 356
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
even with very simple examples eg the following:

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;
}
Even doing:

Code:
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)
Wrangler is offline  
Old 30 September 2021, 09:22   #1294
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 556
Code:
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


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

is working
bebbo is offline  
Old 06 October 2021, 09:17   #1295
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 555
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;
}
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?
BSzili is offline  
Old 06 October 2021, 10:10   #1296
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 326
Best report it on GitHub. Bebbo is usually super responsive there.
pipper is offline  
Old 07 October 2021, 12:14   #1297
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 556
Quote:
Originally Posted by BSzili View Post
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;
}
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.
bebbo is offline  
Old 07 October 2021, 18:08   #1298
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 555
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?
BSzili is offline  
Old 08 October 2021, 16:02   #1299
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 556
Quote:
Originally Posted by BSzili View Post
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
bebbo is offline  
Old 08 October 2021, 17:49   #1300
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 555
Thumbs up

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.
BSzili is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 09:01.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.13705 seconds with 16 queries