GCC 6.2 toolchain for AmigaOS 3 - Page 32

Toni Wilen · 19 January 2018, 13:58

Reason for above mentioned crash is another stack/register parameter conflict. Following memset() expects stack parameters but gets them in registers, causing it to overwrite part of code.

disk.c:

static void fillbuffer(UBYTE *buffer, UBYTE data, globaldata *g)
{
memset (buffer, data + 1, BLOCKSIZE);
}

EDIT: There is also 4 bytes of BSS, where does it come from?. Also is it possible to merge code and data hunks? All data should be read-only anyway. It should also help with absolute addresses.

bebbo · 20 January 2018, 22:53

Quote:

Originally Posted by Toni Wilen

Reason for above mentioned crash is another stack/register parameter conflict. Following memset() expects stack parameters but gets them in registers, causing it to overwrite part of code.

disk.c:

static void fillbuffer(UBYTE *buffer, UBYTE data, globaldata *g)
{
memset (buffer, data + 1, BLOCKSIZE);
}

there are plenty headers where you should add __stdargs. I'm working to add it to the libnix headers atm.

Quote:

Originally Posted by Toni Wilen

EDIT: There is also 4 bytes of BSS, where does it come from?. Also is it possible to merge code and data hunks? All data should be read-only anyway. It should also help with absolute addresses.

It's SysBase. (If you don't strip you can read the symbol names)

I am using your files from 20180114 and there is no BSS my linked executable, since I am using -fbaserel :-) (and -msmall-code)

Code:

2 sections, 0 - 1
sizes: 54664, 2284
hunk 000003e9,        HUNK_CODE,      54664
hunk 000003ec,     HUNK_RELOC32,        312
hunk 000003f0,      HUNK_SYMBOL,          8
HUNK_END
hunk 000003ea,        HUNK_DATA,       2280
hunk 000003ec,     HUNK_RELOC32,        328
hunk 000003f0,      HUNK_SYMBOL,         32
HUNK_END

If you qualify data as const it should already end up in the .text section.
messages.c: UBYTE -> const UBYTE

The functiontables do not end up there, I think it's the function pointers.

So you can reach

Code:

hunk 000003ea,        HUNK_DATA,        656
hunk 000003ec,     HUNK_RELOC32,        332
hunk 000003f0,      HUNK_SYMBOL,         20

wait for fautomat's next push then the __stdargs are live and after building the toolchain again, you are a step further.

Marlon_ · 20 January 2018, 22:57

Using const whenever possible (read-only data) is something everyone should have in mind.

This presentation from CppCon 2016 describes this pretty well:
[ Show youtube player ]

pipper · 21 January 2018, 07:13

This is exactly the presentation that kindled my appetite to come back to the Amiga...
I was thinking "Nowadays there should be really good cross-compilers. Combined with a modern IDE it would make developing for the Amiga a breeze". And then I found beobbo's GCC6 port :-D

alpine9000 · 21 January 2018, 07:15

Quote:

Originally Posted by Marlon_

Using const whenever possible (read-only data) is something everyone should have in mind.

This presentation from CppCon 2016 describes this pretty well:
[ Show youtube player ]

I tried making some of my big data tables const and strangely it made the game run (very slightly) slower. I haven’t checked the generated asm yet yo work out why.

Toni Wilen · 21 January 2018, 11:40

Quote:

Originally Posted by bebbo

It's SysBase. (If you don't strip you can read the symbol names)

I am using your files from 20180114 and there is no BSS my linked executable, since I am using -fbaserel :-) (and -msmall-code)

Code:

2 sections, 0 - 1
sizes: 54664, 2284
hunk 000003e9,        HUNK_CODE,      54664
hunk 000003ec,     HUNK_RELOC32,        312
hunk 000003f0,      HUNK_SYMBOL,          8
HUNK_END
hunk 000003ea,        HUNK_DATA,       2280
hunk 000003ec,     HUNK_RELOC32,        328
hunk 000003f0,      HUNK_SYMBOL,         32
HUNK_END

Section is 2280, allocation size is 2284. All native Amiga utilities shows it as DATA+BSS section.

Quote:

If you qualify data as const it should already end up in the .text section.
messages.c: UBYTE -> const UBYTE

The functiontables do not end up there, I think it's the function pointers.

I missed messages.c, I thought it was already done because const was added everywhere else.

Following remains in data now: (What are those?)

00000290 D _SysBase
00007ffe D ___a4_init
0000028c D __ctype_
00000290 D __edata
00000000 D __sdata

I replaced all memcpy() functions with exec/CopyMem() (struct.h already had a macro for it) but linking without SysBase defined still causes following linker error:

/cygdrive/c/utils/m68k-amigaos/m68k-amigaos/libnix/lib/libb/libnix/libnix.a(memcpy.o)(.text+0xa): undefined reference to `SysBase'

I assume some internal function still needs memcpy()?

PFS3 already defines SysBase = g->SysBase, it does not need static SysBase.

(Yes, this is probably getting too close to useless micro-optimizations but if target is to allow creation of 100% pure programs)

Quote:

wait for fautomat's next push then the __stdargs are live and after building the toolchain again, you are a step further.

memset() still isn't working. Code is identical to previous version:

fillbuffer() and inlined memset():

Code:

40024C10 2f0a                     MOVE.L A2,-(A7) [670000c6]
40024C12 2f02                     MOVE.L D2,-(A7) [670000c6]
40024C14 2448                     MOVEA.L A0,A2
40024C16 31fc 1234 0100           MOVE.W #$1234,$0100 [1234]
40024C1C 2229 00c0                MOVE.L (A1, $00c0) == $40012d40 [00000200],D1
40024C20 6720                     BEQ.B #$20 == $40024c42
40024C22 0280 0000 00ff           AND.L #$000000ff,D0
40024C28 5280                     ADD.L #$01,D0
40024C2A 7440                     MOVE.L #$40,D2
40024C2C b481                     CMP.L D1,D2
40024C2E 640a                     BCC.B #$0a == $40024c3a
40024C30 241f                     MOVE.L (A7)+ [00000000],D2
40024C32 245f                     MOVEA.L (A7)+ [00000000],A2
40024C34 4ef9 4002 bf50           JMP $4002bf50

(#$1234 write is my memwatch breakpoint trigger)

btw, it also has useless and.l+addq.l combination but I guess there is not much to do?

I think this is __memset64()

Code:

4002BF50 48e7 3820                MOVEM.L D2-D4/A2,-(A7)
4002BF54 202f 0014                MOVE.L (A7, $0014) == $40012b44 [40017eac],D0
4002BF58 262f 0018                MOVE.L (A7, $0018) == $40012b48 [00000008],D3
4002BF5C 242f 001c                MOVE.L (A7, $001c) == $40012b4c [4001db98],D2
4002BF60 2203                     MOVE.L D3,D1
4002BF62 e189                     LSL.L #$08,D1
4002BF64 d283                     ADD.L D3,D1
4002BF66 2601                     MOVE.L D1,D3
4002BF68 4843                     SWAP.W D3

Whole toolset was recompiled and strdup.h has recently added __stdargs

bebbo · 21 January 2018, 12:12

Quote:

Originally Posted by Toni Wilen

Section is 2280, allocation size is 2284. All native Amiga utilities shows it as DATA+BSS section.

well, you win :-)

Quote:

Originally Posted by Toni Wilen

I missed messages.c, I thought it was already done because const was added everywhere else.

Following remains in data now: (What are those?)

00000290 D _SysBase
00007ffe D ___a4_init
0000028c D __ctype_
00000290 D __edata
00000000 D __sdata

_SysBase: well known Execbase
___a4_init: only used to load a4 - no real data
__ctype_: something related to ctype.h
__edata: begin of bss
__sdata: begin of data

if you omit some "static" qualifiers you'll figure out, what's in there:
functiontable0
functiontable1000

Quote:

Originally Posted by Toni Wilen

I replaced all memcpy() functions with exec/CopyMem() (struct.h already had a macro for it) but linking without SysBase defined still causes following linker error:

/cygdrive/c/utils/m68k-amigaos/m68k-amigaos/libnix/lib/libb/libnix/libnix.a(memcpy.o)(.text+0xa): undefined reference to `SysBase'

I assume some internal function still needs memcpy()?

PFS3 already defines SysBase = g->SysBase, it does not need static SysBase.

(Yes, this is probably getting too close to useless micro-optimizations but if target is to allow creation of 100% pure programs)

Aiming for that you should omit all libs...
... and you can create pure programs having data+bss. Use -resident instead of -fbaserel then. No wait - you don't wan't the resident startup code^^

Quote:

Originally Posted by Toni Wilen

-memset() still isn't working. Code is identical to previous version:
[...]
Whole toolset was recompiled and strdup.h has recently added __stdargs

Yup, forgot __stdargs there. Added and pushed.

Code:

...
        move.l d1,-(sp)
        move.l d0,-(sp)
        move.l a0,-(sp)
        jsr ___memset64:w(pc)
...

bebbo · 21 January 2018, 12:35

If you don't use a data segment, omit -fbaserel, add missing const, also here:

Code:

static void ShowVersion (globaldata *g)
{
  /* data needed for requester */
  static const struct EasyStruct req =
  {
    sizeof(struct EasyStruct),
    0,
    "Professional File System 3 V" RELEASE,
    (STRPTR)FORMAT_MESSAGE,
    "OK"
  };

Code:

sizes: 57156, 4
hunk 000003e9,        HUNK_CODE,      57156
hunk 000003ec,     HUNK_RELOC32,        832
hunk 000003f0,      HUNK_SYMBOL,          8
HUNK_END
hunk 000003eb,         HUNK_BSS,          4
hunk 000003f0,      HUNK_SYMBOL,          8
HUNK_END

Now only Sysbase remains...
... memcpy is still used...

Code:

#define memcpy(s1,s2,n) (CopyMem((APTR)s2,s1,n),s1)

assroutines.c:

Code:

struct ExecBase *SysBase;

Toni Wilen · 21 January 2018, 13:11

It boots now! And DATA section is completely gone.

Still far too many absolute addresses (RELOC32s). It would be nearly perfect without them

bebbo · 21 January 2018, 16:31

Quote:

Originally Posted by Toni Wilen

It boots now! And DATA section is completely gone.

Still far too many absolute addresses (RELOC32s). It would be nearly perfect without them

feel free to fork and fix

without data segment -mpcrel might help - did you update the zip?

Toni Wilen · 21 January 2018, 16:37

Quote:

Originally Posted by bebbo

feel free to fork and fix

I never touch compilers, sorry

Quote:

without data segment -mpcrel might help - did you update the zip?

Code:

<snip> lots of "using long jump.." messages.</snip>
...
INFO: using long jump from update.o to messages.o:_AFS_ERROR_UPDATE_FAIL
INFO: using long jump from update.o to messages.o:_AFS_ERROR_UPDATE_FAIL
pfs3aio: .data reloc for .data is out of range: 00000000
/cygdrive/c/utils/m68k-amigaos/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: BFD 2.14b 20180118 (adtools build 20080628) internal error, aborting at /cygdrive/c/projects/amigaos-cross-toolchain/submodules/binutils-2.14/bfd/amigaoslink.c line 523 in get_relocated_section_contents

Zip updated.

bebbo · 21 January 2018, 21:56

Quote:

Originally Posted by Toni Wilen

I never touch compilers, sorry

Code:

<snip> lots of "using long jump.." messages.</snip>
...
INFO: using long jump from update.o to messages.o:_AFS_ERROR_UPDATE_FAIL
INFO: using long jump from update.o to messages.o:_AFS_ERROR_UPDATE_FAIL
pfs3aio: .data reloc for .data is out of range: 00000000
/cygdrive/c/utils/m68k-amigaos/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: BFD 2.14b 20180118 (adtools build 20080628) internal error, aborting at /cygdrive/c/projects/amigaos-cross-toolchain/submodules/binutils-2.14/bfd/amigaoslink.c line 523 in get_relocated_section_contents

Zip updated.

Hm, -mpcrel is not working, but -msmall-code does:

Code:

1 sections, 0 - 0
sizes: 57452
hunk 000003e9,        HUNK_CODE,      57452
hunk 000003ec,     HUNK_RELOC32,        892
HUNK_END

bebbo · 22 January 2018, 09:52

Quote:

Code:

<snip> lots of "using long jump.." messages.</snip>

those message might help you to find a "better" order of your object files. (Unfortunately if not found (and did not search thoroughly) an easy way to pass a switch to enable/disable those messages, so they are enabled.)

Toni Wilen · 22 January 2018, 19:50

Yeah, I tried it yesterday and managed to go slightly under 200 relocs, original official version has about 150 and filesize is about the same now.

Some quick comments after checking disassembly (rebuild done today few hours ago)

Some branches use Bcc.W where also Bcc.B would work. Sometimes Bcc.B is used, whats the difference?

For example very beginning of code does this:

00014F06 0c80 0000 1770 CMP.L #$00001770,D0
00014F0C 6400 0044 BCC.W #$0044 == $00014f52

..

00014FAC 2008 MOVE.L A0,D0
00014FAE 6700 0024 BEQ.W #$0024 == $00014fd4
00014FB2 0c6e 0025 0014 CMP.W #$0025,(A6, $0014) == $0000068a [0022]
00014FB8 6400 000a BCC.W #$000a == $00014fc4
00014FBC 6100 ff9a BSR.W #$ff9a == $00014f58
00014FC0 6000 0006 BT .W #$0006 == $00014fc8

CMP.W #0,An vs MOVE.L An,Dn (just mentioning it again).

But this is now mainly nitpicking, it is now good enough

bebbo · 22 January 2018, 21:35

Quote:

Originally Posted by Toni Wilen

Yeah, I tried it yesterday and managed to go slightly under 200 relocs, original official version has about 150 and filesize is about the same now.

Some quick comments after checking disassembly (rebuild done today few hours ago)

Some branches use Bcc.W where also Bcc.B would work. Sometimes Bcc.B is used, whats the difference?
...

My guess (did not look into): bcc.b is only used within a function.
I am even surprised that bcc.b is used^^

Quote:

Originally Posted by Toni Wilen

CMP.W #0,An vs MOVE.L An,Dn (just mentioning it again).

did not put work into it and there are seom caveats due to the way how gcc works. You have to create

Code:

...
  move.l ax,dy
  tst.l dy
...

and the final stage will omit the tst since there are no flag changes.
BUT an earlier pass might try to omit that register move since

Code:

...
  tst.l ax
...

is shorter...
...
...
... maybe I should write my own compiler
...

Quote:

Originally Posted by Toni Wilen

But this is now mainly nitpicking, it is now good enough

And I hope the code is working too.

Toni Wilen · 22 January 2018, 22:04

Quote:

Originally Posted by bebbo

My guess (did not look into): bcc.b is only used within a function.
I am even surprised that bcc.b is used^^

I forgot that beginning of code starts with assembly part (startup.s), I thought it was C-code..

It is startup.s has those word branches. Shouldn't assembler handle this automatically? At least when branch target is in same file.

Branches generated from C-code seems to use .B when possible. (Which is nice)

Quote:

And I hope the code is working too.

It boots but listing directory causes a crash (writes to address zero in KS ROM memory pool code which most likely mean memory corruption somewhere else).

-O1 works, -Os and -O2 crashes identically. I'll debug this later..

EDIT: I didn't test directory listing previously, it may or may not have worked previously. Most likely not

Toni Wilen · 23 January 2018, 11:14

This is getting difficult to debug. Reason for crash (at least with -O2) is support.c/FreePooledVec() being called with invalid "g" parameter. (It is valid looking pointer but points 3340 bytes too far)

I guess this is the final reason that requires me to implement debug hunk support to uae debugger..

Toni Wilen · 23 January 2018, 20:21

-O2 bug:

Code:

void FreeListEntry(listentry_t *entry, globaldata *g)
{
#define fe ((fileentry_t *)entry)
	if (IsFileEntry(entry) && fe->anodechain)
		DetachAnodeChain(fe->anodechain, g);
	FreeMemP(entry, g);
#undef fe
}

Becomes

Code:

400232B2 2f0b                     MOVE.L A3,-(A7) [00000000]
400232B4 2f0a                     MOVE.L A2,-(A7) [00000000]
400232B6 2448                     MOVEA.L A0,A2
400232B8 2649                     MOVEA.L A1,A3
400232BA 1028 001d                MOVE.B (A0, $001d) == $226a014f,D0
400232BE 0200 000c                AND.B #$0c,D0
400232C2 0c00 0008                CMP.B #$08,D0
400232C6 670c                     BEQ.B #$0c == $400232d4
400232C8 204a                     MOVEA.L A2,A0 ; FreeMemP "entry" parameter
400232CA 226b 012e                MOVEA.L (A3, $012e) == $40012dae [4002794e],A1 // globaldata->freememp function pointer
400232CE 245f                     MOVEA.L (A7)+ [40013bf4],A2
400232D0 265f                     MOVEA.L (A7)+ [40013bf4],A3
400232D2 4ed1                     JMP (A1) ; Jump to freememp but A1 should be freememp "g" parameter
400232D4 2068 003a                MOVEA.L (A0, $003a) == $226a016c,A0
400232D8 b0fc 0000                CMPA.W #$0000,A0
400232DC 67ea                     BEQ.B #$ea == $400232c8
400232DE 4eba 2ed6                JSR (PC,$2ed6) == $400261b6
400232E2 204a                     MOVEA.L A2,A0
400232E4 226b 012e                MOVEA.L (A3, $012e) == $40012dae [4002794e],A1 // same
400232E8 245f                     MOVEA.L (A7)+ [40013bf4],A2
400232EA 265f                     MOVEA.L (A7)+ [40013bf4],A3
400232EC 4ed1                     JMP (A1) // and same

bebbo · 23 January 2018, 21:12

Quote:

Originally Posted by Toni Wilen

-O2 bug:

Code:

void FreeListEntry(listentry_t *entry, globaldata *g)
{
#define fe ((fileentry_t *)entry)
    if (IsFileEntry(entry) && fe->anodechain)
        DetachAnodeChain(fe->anodechain, g);
    FreeMemP(entry, g);
#undef fe
}

Becomes

Code:

; push regs
400232B2 2f0b                     MOVE.L A3,-(A7) [00000000]
400232B4 2f0a                     MOVE.L A2,-(A7) [00000000]
...
; pop regs
400232CE 245f                     MOVEA.L (A7)+ [40013bf4],A2
400232D0 265f                     MOVEA.L (A7)+ [40013bf4],A3
; tail jump
400232D2 4ed1                     JMP (A1) ; Jump to freememp but A1 should be freememp "g" parameter
...

looks like you're also a victim of this issue: https://github.com/bebbo/gcc/issues/14

bebbo · 23 January 2018, 21:13

Quote:

Originally Posted by Toni Wilen

This is getting difficult to debug. Reason for crash (at least with -O2) is support.c/FreePooledVec() being called with invalid "g" parameter. (It is valid looking pointer but points 3340 bytes too far)

I guess this is the final reason that requires me to implement debug hunk support to uae debugger..

does it support c-source level debugging?

19 January 2018, 13:58	#621
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	Reason for above mentioned crash is another stack/register parameter conflict. Following memset() expects stack parameters but gets them in registers, causing it to overwrite part of code. disk.c: static void fillbuffer(UBYTE buffer, UBYTE data, globaldata g) { memset (buffer, data + 1, BLOCKSIZE); } EDIT: There is also 4 bytes of BSS, where does it come from?. Also is it possible to merge code and data hunks? All data should be read-only anyway. It should also help with absolute addresses. Last edited by Toni Wilen; 19 January 2018 at 14:39.

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

20 January 2018, 22:57	#623
Marlon_ AmigaDev.com Join Date: Mar 2016 Location: Stockholm, Sweden Age: 35 Posts: 625	Using const whenever possible (read-only data) is something everyone should have in mind. This presentation from CppCon 2016 describes this pretty well: [ Show youtube player ]

21 January 2018, 07:13	#624
pipper Registered User Join Date: Jul 2017 Location: San Jose Posts: 652	This is exactly the presentation that kindled my appetite to come back to the Amiga... I was thinking "Nowadays there should be really good cross-compilers. Combined with a modern IDE it would make developing for the Amiga a breeze". And then I found beobbo's GCC6 port :-D

21 January 2018, 13:11	#629
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	It boots now! And DATA section is completely gone. Still far too many absolute addresses (RELOC32s). It would be nearly perfect without them

22 January 2018, 19:50	#634
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	Yeah, I tried it yesterday and managed to go slightly under 200 relocs, original official version has about 150 and filesize is about the same now. Some quick comments after checking disassembly (rebuild done today few hours ago) Some branches use Bcc.W where also Bcc.B would work. Sometimes Bcc.B is used, whats the difference? For example very beginning of code does this: 00014F06 0c80 0000 1770 CMP.L #$00001770,D0 00014F0C 6400 0044 BCC.W #$0044 == $00014f52 .. 00014FAC 2008 MOVE.L A0,D0 00014FAE 6700 0024 BEQ.W #$0024 == $00014fd4 00014FB2 0c6e 0025 0014 CMP.W #$0025,(A6, $0014) == $0000068a [0022] 00014FB8 6400 000a BCC.W #$000a == $00014fc4 00014FBC 6100 ff9a BSR.W #$ff9a == $00014f58 00014FC0 6000 0006 BT .W #$0006 == $00014fc8 CMP.W #0,An vs MOVE.L An,Dn (just mentioning it again). But this is now mainly nitpicking, it is now good enough

23 January 2018, 11:14	#637
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,505	This is getting difficult to debug. Reason for crash (at least with -O2) is support.c/FreePooledVec() being called with invalid "g" parameter. (It is valid looking pointer but points 3340 bytes too far) I guess this is the final reason that requires me to implement debug hunk support to uae debugger..

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)