English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. C/C++ (http://eab.abime.net/forumdisplay.php?f=118)
-   -   GCC 6.2 toolchain for AmigaOS 3 (http://eab.abime.net/showthread.php?t=85474)

bebbo 04 January 2019 22:39

1000!

alkis 04 January 2019 23:45

Quote:

Originally Posted by bebbo (Post 1295257)
...
2. no idea guess hth313 is right here and it's too simple that even without optimizer that variable is discarded.

generated code

Isn't -8(a5) the 't' variable?

cdh 05 January 2019 00:23

I'm not great at reading 68k assembler, but think it's the a0 value after this statement:
add.l d0,a0

hth313 05 January 2019 00:41

Quote:

Originally Posted by alkis (Post 1295268)
Isn't -8(a5) the 't' variable?

Probably, though it can also be an introduced temporary with no real name that happens to behave the same as 't'. Given the quite rudimentary code generation model displayed here, I would however lean towards that you are most likely correct.

In any case, debug information is not done right or incorrectly interpreted on the debugger side.

hth313 05 January 2019 00:43

Quote:

Originally Posted by cdh (Post 1295277)
I'm not great at reading 68k assembler, but think it's the a0 value after this statement:
add.l d0,a0

That is the address of it. It is dereferenced on the following line
move.l (a0),-8(a5)
where the value is stored on the stack using the A5 frame pointer.

_dante_ 05 January 2019 01:33

Quote:

Originally Posted by hth313 (Post 1295280)
In any case, debug information is not done right or incorrectly interpreted on the debugger side.

So, very likely it means that debug information generated by gcc 6.4.1 compiler is not or could be not fully compatible with the gdb 8.2.50 debugger and to solve such compatibility issues changes on the compiler side in terms of debug information generation are required :sad

bebbo 05 January 2019 11:34

Quote:

Originally Posted by _dante_ (Post 1295296)
So, very likely it means that debug information generated by gcc 6.4.1 compiler is not or could be not fully compatible with the gdb 8.2.50 debugger and to solve such compatibility issues changes on the compiler side in terms of debug information generation are required :sad

the debug info is ok:
Code:

00000214 <_main>:
#include <stdio.h>

int main(int argc, char **argv) {
    214:      4e55 fff8      link.w a5,#-8
        puts("hello world!");
    218:      487a ffd6      pea 1f0 <___exitcpp+0x18>(pc)
    21c:      4eb9 0000 0bb0  jsr bb0 <_puts>
    222:      588f            addq.l #4,sp
        printf("argc=%ld\r\n", argc);
    224:      2f2d 0008      move.l 8(a5),-(sp)
    228:      487a ffd3      pea 1fd <___exitcpp+0x25>(pc)
    22c:      4eb9 0000 0a94  jsr a94 <_printf>
    232:      508f            addq.l #8,sp
        for (int i = 0; i < argc; ++i) {
    234:      42ad fffc      clr.l -4(a5)
    238:      6024            bra.s 25e <_main+0x4a>
                char *t = argv[i];
    23a:      202d fffc      move.l -4(a5),d0
    23e:      e588            lsl.l #2,d0
    240:      206d 000c      movea.l 12(a5),a0
    244:      d1c0            adda.l d0,a0
    246:      2b50 fff8      move.l (a0),-8(a5)
                printf("arg=%s\r\n", t);
    24a:      2f2d fff8      move.l -8(a5),-(sp)
    24e:      487a ffb8      pea 208 <___exitcpp+0x30>(pc)
    252:      4eb9 0000 0a94  jsr a94 <_printf>
    258:      508f            addq.l #8,sp
        for (int i = 0; i < argc; ++i) {
    25a:      52ad fffc      addq.l #1,-4(a5)
    25e:      202d fffc      move.l -4(a5),d0
    262:      b0ad 0008      cmp.l 8(a5),d0
    266:      6dd2            blt.s 23a <_main+0x26>
        }
        return 0;
    268:      7000            moveq #0,d0
}
    26a:      4e5d            unlk a5
    26c:      4e75            rts


alkis 06 January 2019 10:36

Git pull/make update/make all breaks today on newlib

Code:

make[7]: Entering directory '/home/alex/t/amiga-gcc/build-Linux/newlib/libm020/newlib/libc'
rm -f libc.a
rm -rf tmp
mkdir tmp
cd tmp; \
 for i in argz/lib.a stdlib/lib.a ctype/lib.a search/lib.a stdio/lib.a  string/lib.a signal/lib.a time/lib.a locale/lib.a reent/lib.a  errno/lib.a misc/lib.a ssp/lib.a    machine/lib.a sys/lib.a; do \
  m68k-amigaos-ar x ../$i; \
 done; \
m68k-amigaos-ar rc ../libc.a *.o
m68k-amigaos-ar: ../sys/lib.a: No such file or directory
m68k-amigaos-ranlib libc.a
rm -rf tmp
rm -f crt0.o
ln sys/crt0.o crt0.o >/dev/null 2>/dev/null || cp sys/crt0.o crt0.o
cp: cannot stat 'sys/crt0.o': No such file or directory
Makefile:1045: recipe for target 'crt0.o' failed


bebbo 06 January 2019 15:03

Quote:

Originally Posted by alkis (Post 1295543)
Git pull/make update/make all breaks today on newlib

Code:

make[7]: Entering directory '/home/alex/t/amiga-gcc/build-Linux/newlib/libm020/newlib/libc'
rm -f libc.a
rm -rf tmp
mkdir tmp
cd tmp; \
 for i in argz/lib.a stdlib/lib.a ctype/lib.a search/lib.a stdio/lib.a  string/lib.a signal/lib.a time/lib.a locale/lib.a reent/lib.a  errno/lib.a misc/lib.a ssp/lib.a    machine/lib.a sys/lib.a; do \
  m68k-amigaos-ar x ../$i; \
 done; \
m68k-amigaos-ar rc ../libc.a *.o
m68k-amigaos-ar: ../sys/lib.a: No such file or directory
m68k-amigaos-ranlib libc.a
rm -rf tmp
rm -f crt0.o
ln sys/crt0.o crt0.o >/dev/null 2>/dev/null || cp sys/crt0.o crt0.o
cp: cannot stat 'sys/crt0.o': No such file or directory
Makefile:1045: recipe for target 'crt0.o' failed


you need to run
Code:

make clean-prefix
or manually update the header file lib\gcc\m68k-amigaos\6.4.1b\include\c++\cstdlib with amiga-gcc\projects\gcc\libstdc++-v3\include\c_global\cstdlib

alkis 06 January 2019 16:42

Quote:

Originally Posted by bebbo (Post 1295584)
you need to run
Code:

make clean-prefix
or manually update the header file lib\gcc\m68k-amigaos\6.4.1b\include\c++\cstdlib with amiga-gcc\projects\gcc\libstdc++-v3\include\c_global\cstdlib

Yeap. Worked as a charm. Thanks!

NovaCoder 08 January 2019 00:47

Quote:

Originally Posted by arti (Post 1294710)
It just doesn't work for most stuff I tried.

It'a a great effort and I hope it to be usable one day.

I agree with Arti, I've tried using GCC 6.2 to build a few of my old ports and haven't managed to get anything to run properly unfortunately. It works fine with small projects and libraries but no luck with larger projects yet.

pipper 08 January 2019 00:52

That’s a bit hand wavy. Can you elaborate? Does it not compile? Does it not link? Does it not run? Does it run but crash?
In either case please show more details.

I have been compiling large projects like Dopus5 and ScummVM and all my initial problems with the compiler have been ironed out by Bebbo diligently. The last big things I’m hoping for are better debugging and LTO :)

NovaCoder 08 January 2019 01:18

Quote:

Originally Posted by pipper (Post 1295959)
That’s a bit hand wavy. Can you elaborate? Does it not compile? Does it not link? Does it not run? Does it run but crash?
In either case please show more details.

I have been compiling large projects like Dopus5 and ScummVM and all my initial problems with the compiler have been ironed out by Bebbo diligently. The last big things I’m hoping for are better debugging and LTO :)

I can't provide any detailed debug info that will help unfortunately. I first tried building an SDL library which worked perfectly and then I tried building a version of AmiQuake which although it ran it was having memory issues which resulted in screen glitches. After that I tired compiling my port of DosBox which would just crash immediately on start up.

Not taking anything away from this updated version of GCC which is one the best things to come to classic Amiga development in recent years :D

Marlon_ 08 January 2019 04:00

I've managed to get Milkytracker running, which is a fairly large C++ project. I've also managed to get Robin Hood demo running together with arczi/arti.

The optimization in GCC6 needs to be tweaked though, a lot of the time, lowering to -O0/-O1 can get stuff running, while -O2 and higher does weird things.

I've managed to get Milkytracker stable on -O3 by working together with Bebbo to iron out the bugs. So don't expect stuff to magically happen without working together with Bebbo to figure out what's going wrong.

Arczi and Bebbo are currently looking into why anything above -O1 fails on the Robin Hood demo, afaik.

NovaCoder 08 January 2019 04:16

Quote:

Originally Posted by Marlon_ (Post 1295997)
I've managed to get Milkytracker running, which is a fairly large C++ project. I've also managed to get Robin Hood demo running together with arczi/arti.

The optimization in GCC6 needs to be tweaked though, a lot of the time, lowering to -O0/-O1 can get stuff running, while -O2 and higher does weird things.

I've managed to get Milkytracker stable on -O3 by working together with Bebbo to iron out the bugs. So don't expect stuff to magically happen without working together with Bebbo to figure out what's going wrong.

Arczi and Bebbo are currently looking into why anything above -O1 fails on the Robin Hood demo, afaik.

That's very interesting, I built everything with -O2 so maybe that's why I was having issues, I'll try again with -OO/O1

Thanks

alpine9000 08 January 2019 05:57

Another thing to try is -O2 but with -fbbb=-

This enables the default GCC optimisations but disables the new bebbo optimisations. If it works with the above but fails with -O2, there is a good chance you have discovered a bug in the bebbo optimisations.

If that is the case, you can then narrow it down by enabling/disabling each bebbo optimisation with
-fbbb=abcefilmprsz until you discover which letter is causing the issue.

NovaCoder 08 January 2019 06:04

Quote:

Originally Posted by alpine9000 (Post 1296014)
Another thing to try is -O2 but with -fbbb=-

This enables the default GCC optimisations but disables the new bebbo optimisations. If it works with the above but fails with -O2, there is a good chance you have discovered a bug in the bebbo optimisations.

If that is the case, you can then narrow it down by enabling/disabling each bebbo optimisation with
-fbbb=abcefilmprsz until you discover which letter is causing the issue.

Great, very helpful. Thanks :)

pipper 08 January 2019 07:13

...or upload your stuff to github and crowdsource the debugging ;)

bebbo 08 January 2019 09:18

Quote:

Originally Posted by alpine9000 (Post 1296014)
Another thing to try is -O2 but with -fbbb=-

This enables the default GCC optimisations but disables the new bebbo optimisations. If it works with the above but fails with -O2, there is a good chance you have discovered a bug in the bebbo optimisations.

If that is the case, you can then narrow it down by enabling/disabling each bebbo optimisation with
-fbbb=abcefilmprsz until you discover which letter is causing the issue.

My usual approach (yes, still happens then and now, prayers do not work out) is
- build all files in folder X
- copy all .o files into folder A
- build all files with -fbbb=- in folder X
- copy all .o files int folder B

now link and test in folder X. With -fbbb=- it should run if not try a different -O* option until files in folders X and B do work

now do a binary search:
1. copy half of the files from A to X
2. link and test
3. if ok repeat at 1. for the remaining files in A
4. if not replace the last copied files with files from B
5. go to 1 and check only the last copied files

at the end you have one file which causes the trouble.
now try the different letters to search which one is the bad guy

start with omitting 'e' then 'r' from the list of letters.

once found the offending letter, create asm files and compare these - maybe that's my job then^^

sometimes I'm still amazed at what my optimizers can do. not bad at all for random hacking :spin

and use the latest version: gcc version 6.4.1b 20190106170304

Marlon_ 08 January 2019 09:19

Quote:

Originally Posted by pipper (Post 1296019)
...or upload your stuff to github and crowdsource the debugging ;)



+1

Amigans need to get out of the “keep it to myself” mentality, especially when it’s about open source code with licenses that explicitly states the source and its changes need to be shared if an executable is published.


All times are GMT +2. The time now is 05:23.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.

Page generated in 0.15435 seconds with 11 queries