@sTix Newlib version will crash when perfomance-monitor not found (just forgotten null-pointer check). It is fixed in beta, but then it make no big difference for public release, as it will just silencly exit, without creating any gmon.out because perfomance monitor for x5000/Tabor were added just some weeks ago and currently in testing.
For clib2 build you will have no crash, but you will also have no gmon.out file created, because of the same "no perfomance monitor available for x5000 on public kernels"
Currently in the public, the only way to test all those things for us, it just grab my test gmon.out's from there:
And to try to understand why current version of gprof didn't parse output correctly. At least to know if it "-pg" generate "wrong" code. Or it is gprof itself can't read it as expected.
At least in case with clib2, we have all the "-pg / creating of gmon.out" related code there:
Of course some bits also in gcc/binutils itself (to handle part of "-pg" switch), dunno where at the moment..
EDIT: I think i also can go that route : install on cross-compiler VERY old SDK, just the first one or so. Then can try to build things with -pg / use gprof /etc, to see, if/when things start to work (or not) at all. And step by step can rule out things.
@sTix SIGPROF is part of the ISO standard but under posix 1-2001 and susv, posix is it's own standard under ieee 1003 And iso 9945 the latest version is IEEE Std 1003.1-2017 It is compromised of Quote:
Parts before 1997 Before 1997, POSIX comprised several standards:
POSIX.1: Core Services (incorporates Standard ANSI C) (IEEE Std 1003.1-1988) Process Creation and Control Signals Floating Point Exceptions Segmentation / Memory Violations Illegal Instructions Bus Errors Timers File and Directory Operations Pipes C Library (Standard C) I/O Port Interface and Control Process Triggers POSIX.1b: Real-time extensions (IEEE Std 1003.1b-1993, later appearing as librt—the Realtime Extensions library)[9]) Priority Scheduling Real-Time Signals Clocks and Timers Semaphores Message Passing Shared Memory Asynchronous and Synchronous I/O Memory Locking Interface POSIX.1c: Threads extensions (IEEE Std 1003.1c-1995) Thread Creation, Control, and Cleanup Thread Scheduling Thread Synchronization Signal Handling POSIX.2: Shell and Utilities (IEEE Std 1003.2-1992) Command Interpreter Utility Programs
Versions after 1997 After 1997, the Austin Group developed the POSIX revisions. The specifications are known under the name Single UNIX Specification, before they become a POSIX standard when formally approved by the ISO. 8 POSIX.1-2001 (with two TCs)
POSIX.1-2001 (or IEEE Std 1003.1-2001) equates to the Single UNIX Specification version 3.[10]
This standard consisted of:
the Base Definitions, Issue 6, the System Interfaces and Headers, Issue 6, the Commands and Utilities, Issue 6.
IEEE Std 1003.1-2004 involved a minor update of POSIX.1-2001. It incorporated two minor updates or errata referred to as Technical Corrigenda (TCs).[11] Its contents are available on the web.[12]
POSIX.1-2008 (with two TCs)
Base Specifications, Issue 7 (or IEEE Std 1003.1-2008, 2016 Edition) is similar to the current 2017 version (as of 22 July 2018).[13][14]
This standard consists of:
the Base Definitions, Issue 7, the System Interfaces and Headers, Issue 7, the Commands and Utilities, Issue 7,
the Rationale volume.POSIX.1-2017
IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) - IEEE Standard for Information Technology—Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7 is available from either The Open Group or IEEE and is, as of 22 July 2018, the current standard. It is technically identical to POSIX.1-2008 with Technical Corrigenda 1 and 2 applied. A free online copy may still be available.[13]
I just can't find any tool except gprof that can read gmon.out. It would be nice to know if it's gprof itself that's broken, or if gmon.out contains garbage.
@sTix Btw, it seems we soon or later need to deal with updating Binutils. The latest GCC 11 start to use dwarf-5 as default, and most of our stuff from current Binutils start to bring errors. It still works correctly mostly, but still, when you build things not just with -gstabs, but with anything else, there are screams about dwarf-5 not being supported in BFD.
@sTix Btw, can you clarify a bit one more time situation with Clib2 ?
I mean, did i understand right, that sba/adtools is the latest public stuff we got in terms of gcc/binutils, but when it comes to clib2, then what we have on the sba/adtools are outdated stuff, and we can not need to rely on it. The one which is the last one is https://github.com/adtools/clib2, and your changes on clib2 you want to push there, that correct?
I just see on your clib2 forked repo, that you have a lot of changes done but they all mark as "Some checks were not successful"...
In other words, if one wants to contribute to clib2 and does not want to face an unmaintained pull request, is it mean that better to use your repo for now?
ps. Is your mail that ola.soder at axis current one?
I mean, did i understand right, that sba/adtools is the latest public stuff we got in terms of gcc/binutils
Correct, Sebastian is very quick to respond to PR:s so sba1/adtools is always up to date.
Quote:
but when it comes to clib2, then what we have on the sba/adtools are outdated stuff, and we can not need to rely on it
No, when you build adtools you get the latest stable from my clib2 fork (it's unfortunate that it exists at all, but it is what it is, you know the history :)).
If you look in 'native-build/makefile' in adtools you'll find the following lines:
The SHA1 refers to HEAD of the 'main' branch in sodero/clib2 (not 'master', that's full of experiments).
Summary: - sba1/adtools is always up to date. - PR:s for clib2 should be made for the 'main' branch in sodero/clib2. - Once the clib2 PR is merged another PR with an updated CLIB2_SHA1 should be made for 'master' in sba1/adtools.
Quote:
ps. Is your mail that ola.soder at axis current one?
Yes, but I tend to not read e-mails during the weekends, too much work related things pop up.
@sTix What is interesting, is that indeed, when one builds GCC/Binutils via cross-compiler, then "-flto" just works as expected. If that builds for native versions, then once you tried to use "-flto", you have back "-f may not be used without -shared", then if I add "-shared" it builds, but of course didn't. While, on cross-compiler (the same version of GCC, etc), everything works without -shared and no error of such kind.
It's like something wrong with ldscripts maybe on the native side or something... I mean it surely not the binaries issue, but configuration one.
What is interesting is why for native build with have --disable-nls ? I read it is for disabling localizations, just curious if it is still the case. But probably is it, as once things refer to localisations it means a lot piece of work for no benefits (especially for compilers, etc).
@Walkero This line is exactly enabling lto, which we need, and which we need to fix to work on native build. I.e. those lines are new, for enabling lto, yes.
@walkero Yes, lto enabled on native build too, but not working on the native build, because we do not have --enable-plugin for native builds as well (i.e. not only enabling of lto need it, but also --enable-plugin to make them works). At least, --enable-plugin is enabled for cross-compiling, and it works, for native, it is not, and it didn't work.
I.e. 2 options should be set to for compiler to make lto works. One which you point out, and additional --enable-plugin (because lto is a kind of plugin). But this one should be set in binutils Makefile as Sodero shown
By "working fine", you should be able to do "ppc-amigaos-gcc -flto test.c -o test" , and the test case should be compiled (see -flto option added) and be smaller by size in comparison with one when compiled without -flto.
Maybe it has to do with my compiling environment. I will investigate more.
I'm not in front of a proper machine right now so I can't do any real digging but it looks like there could be a dlopen() problem. In the configure script in binutils/bfd you'll see that enable_dlopen isn't set if you search for the error message you showed.
If you look in native-build/binutils-native-something/bfd you should find a config.log. That's the autotools output from the configure step. In that one you might find some dlopen related clues.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
