GCC 6.2 toolchain for AmigaOS 3

[Hewitson]

Originally Posted by _dante_

Regarding the "awk: ... makes too many open files" - maybe usage of 'gawk' installed using 'brew' is getting rid of these errors, as I have it installed to override Apple's awk and I didn't get that error while building libnix.

macOS awk is well known for not being 100% compatible with gawk.

[bebbo]

Originally Posted by Hewitson

macOS awk is well known for not being 100% compatible with gawk.

macOS is well known to be a crappy wanker operating system.

SCNR

[Hewitson]

I used Linux & BSD for years. Their package management systems suck and none of the window managers ever appealed to me. In fact I stuck with twm for many years just to avoid the bloatware.

macOS is fast, reliable, and honestly, an absolute pleasure to use. A fantastic OS.

[arti]

Originally Posted by bebbo

your toolchain does not support the amiga hunk format.

Too bad, I try to compile it in elf but it's plain stupid.

/mnt/e/usr/local/amiga/m68k-amigaos/clib/cross/bin/../lib/gcc/m68k-unknown-amigaos/3.4.6/../../../../m68k-unknown-amigaos/include/stdlib.h:43:25: 

no include path in which to search for stdlib.h

Why it needs another stdlib.h ...

WTF?!

[Marlon_]

Why don’t you use gcc6? What is the reason for still using gcc3?

[arti]

It just doesn't work for most stuff I tried.

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

[Samurai_Crow]

The GCC 3 parser is loose enough to drive a train through and GCC 6 isn't, in other words.

[Marlon_]

Originally Posted by Samurai_Crow

The GCC 3 parser is loose enough to drive a train through and GCC 6 isn't, in other words.

the gcc6 toolchain is more than usable.

[arti]

Try a big c++ project.

[Marlon_]

Originally Posted by arti

Try a big c++ project.

I have

[arti]

Can you go to #ap...-co.e ?

[Marlon_]

Originally Posted by arti

Can you go to #ap...-co.e ?

Not by a computer, I’ll let you know when I’m available

[bebbo]

Originally Posted by arti

Can you go to #ap...-co.e ?

I googled that without useful result...
... please use ecplicit lyrics!


And to keep the community happy/tormale/whatever, I have created a tutorial for Eclipse as an IDE for programming and debugging Amiga applications.

https://franke.ms/amiga/gdb-eclipse.wiki

[arti]

How can I fix this ?

/amiga-gcc/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: different object file formats composing set ___CTOR_LIST__
/amiga-gcc/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: different object file formats composing set ___DTOR_LIST__

[Samurai_Crow]

Sounds like the constructors and destructors aren't compiled to the same object code format. A clean rebuild of all .o and .a files is in order by the sound of it.

[arti]

Didn't help.

[bebbo]

Originally Posted by arti

How can I fix this ?

/amiga-gcc/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: different object file formats composing set ___CTOR_LIST__
/amiga-gcc/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: different object file formats composing set ___DTOR_LIST__

could you provide more info please?
Maybe share the project somehow??

[_dante_]

It looks that I found unwanted compiler optimization - when it comes to debugging...

I have a simple hello.c code:

#include <stdio.h>

int main(int argc, char **argv) {
        puts("hello world!");
        printf("argc=%ld\r\n", argc);
        for (int i = 0; i < argc; ++i) {
                char *t = argv[i];
                printf("arg=%s\r\n", t);
        }
        return 0;
}

I built debuggable executable using simple command without optimizations or other fancy flags.

m68k-amigaos-gcc hello.c -g -noixemul -o hello-noixemul

Then I run it on FS-UAE using bgdbserver 0.5... and started debugging...


Below is the console snapshot from the same point in time as on the above FS-UAE screenshot. I bolded sections I would ask for.

$ m68k-amigaos-gdb hello-noixemul
GNU gdb (GDB) 8.2.50.20181223-111052-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin18.2.0 --target=m68k-amigaos".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from hello-noixemul...done.
(gdb) target remote :2345
Remote debugging using :2345
warning: Target reported unsupported offsets: Text=680246d8;Data=68018d78;Bss=68017a88;
warning: Target reported unsupported offsets: Text=680246d8;Data=68018d78;Bss=68017a88;
0x680246d8 in _stext ()
(gdb) list
1	#include <stdio.h>
2	
3	int main(int argc, char **argv) {
4	        puts("hello world!");
5	        printf("argc=%ld\r\n", argc);
6	        for (int i = 0; i < argc; ++i) {
7	                char *t = argv[i];
8	                printf("arg=%s\r\n", t);
9	        }
10	        return 0;
(gdb) b 8
Breakpoint 1 at 0x680247fe: file hello.c, line 8.
(gdb) c
Continuing.

Breakpoint 1, main (argc=7, argv=0x680186b4) at hello.c:8
8	                printf("arg=%s\r\n", t);
(gdb) c
Continuing.

Breakpoint 1, main (argc=7, argv=0x680186b4) at hello.c:8
8	                printf("arg=%s\r\n", t);
(gdb) c
Continuing.

Breakpoint 1, main (argc=7, argv=0x680186b4) at hello.c:8
8	                printf("arg=%s\r\n", t);
(gdb) c
Continuing.

Breakpoint 1, main (argc=7, argv=0x680186b4) at hello.c:8
8	                printf("arg=%s\r\n", t);
(gdb) info local
i = 3
(gdb) p argv[i]
$1 = 0x68018691 "ccc"
(gdb) p t
No symbol "t" in current context.
(gdb) 

1. What does these warnings mean? Why 'unsupported offsets'? Is that okay that these offsets are in fact hunk offsets presented by bgdbserver but additionally shifted by 4 bytes?

2. Symbol "t" is declared and assigned at line 7, then used at line 8, but gdb does not show it as a valid symbol in this context (info local, p t at the end of console snapshot) - p i of course works in this context too. The result printed out to the screen is correct so there must be some kind of optimization in this place like 'putting t symbol into address register' - but why if I didn't compile sources with any of the -O flags?

[hth313]

I cannot answer all your questions, but the reason there is no symbol "t" I can at least speculate on.

Symbol "t" is only use as a temporary once and the compiler may decide to just rewrite the call to

printf("arg=%s\r\n", [argv[i]);

and eliminate the variable. It may decide to perform certain rewrites no matter if you enabled optimization or not. (I am not going to argue whether that is desirable or not, just that such is life.)

There may be some option to advice the compiler to produce more debuggable output, I do not know.

Even if the compiler does such rewrites, the debug information (DWARF) can express that the variable exists and have a given value, also when it does not correspond to any actual physical location of its own. I suppose that this is not implemented or done here.

[bebbo]

Originally Posted by _dante_

It looks that I found unwanted compiler optimization - when it comes to debugging...

1.
...
(gdb) target remote :2345
Remote debugging using :2345
warning: Target reported unsupported offsets: Text=680246d8;Data=68018d78;Bss=68017a88;
warning: Target reported unsupported offsets: Text=680246d8;Data=68018d78;Bss=68017a88;
0x680246d8 in _stext ()


2. Symbol "t" is declared and assigned at line 7, then used at line 8, but gdb does not show it as a valid symbol in this context (info local, p t at the end of console snapshot) - p i of course works in this context too. The result printed out to the screen is correct so there must be some kind of optimization in this place like 'putting t symbol into address register' - but why if I didn't compile sources with any of the -O flags?

1. in modern systems there is always one linear address space for the program. The Amiga is different.
It's just an information and don't plan to remove that warnings.

2. no idea guess hth313 is right here and it's too simple that even without optimizer that variable is discarded.