Overlap

[thetechknight]

The compiler makefile for the 68k_example is set for -O0, which is basically no optimization.

I used the example skeleton for my CPU, and ported it over to the MC68010. Works fine, but I wanted to optimize the code a bit more for speed.

-O1 works fine. but -O2 or -O3, I get an Overlap Error:

m68k-elf-gcc -m68010 -I. -DREENTRANT_SYSCALLS_PROVIDED -D_REENT_SMALL -Wall -O2 -std=gnu99 -g -c -o glue.o glue.c m68k-elf-gcc -m68010 -I. -DREENTRANT_SYSCALLS_PROVIDED -D_REENT_SMALL -Wall -O2 -std=gnu99 -g -c -o uart.o uart.c m68k-elf-gcc -c -Wa,-adhlns=crt0.S.lst crt0.S -o crt0.o m68k-elf-gcc -c -Wa,-adhlns=vector.S.lst vector.S -o vector.o "---> link project to RAM ..." m68k-elf-gcc crt0.o vector.o main.o appinit.o glue.o uart.o -m68010 -g -nostart files -Wl,--script=ram.ld,-Map=CPU.map,--allow-multiple-definition -o CPU.elf c:/msys64/home/user/toolchain68k/toolchain-m68k-elf-current/bin/../lib/gcc/m68k- elf/9.2.0/../../../../m68k-elf/bin/ld.exe: section .text.startup LMA [0000000000 012a00,0000000000012a41] overlaps section .data LMA [0000000000012a00,0000000000 012f0f] collect2.exe: error: ld returned 1 exit status make: *** [CPU.elf] Error 1

I left the ram.ld script pretty much alone, I did change the memory locations and I even tried increasing the size to the max size of my system, but it didnt change anything.

Edit: This is with your stock toolchain, built as-is.

[haarer]

Hi, it is hard to diagnose for me at the moment. No Computer at Hand.

Can you try a minimal linker Script ? It is explained in that Page very good:

http://www.scoberlin.de/content/media/http/informatik/gcc_docs/ld_3.html

Am 6. Dezember 2019 04:39:57 MEZ schrieb mbates14 notifications@github.com:

The compiler makefile for the 68k_example is set for -O0, which is basically no optimization.

I used the example skeleton for my CPU, and ported it over to the MC68010. Works fine, but I wanted to optimize the code a bit more for speed.

-O1 works fine. but -O2 or -O3, I get an Overlap Error:

m68k-elf-gcc -m68010 -I. -DREENTRANT_SYSCALLS_PROVIDED -D_REENT_SMALL -Wall -O2 -std=gnu99 -g -c -o glue.o glue.c m68k-elf-gcc -m68010 -I. -DREENTRANT_SYSCALLS_PROVIDED -D_REENT_SMALL -Wall -O2 -std=gnu99 -g -c -o uart.o uart.c m68k-elf-gcc -c -Wa,-adhlns=crt0.S.lst crt0.S -o crt0.o m68k-elf-gcc -c -Wa,-adhlns=vector.S.lst vector.S -o vector.o "---> link project to RAM ..." m68k-elf-gcc crt0.o vector.o main.o appinit.o glue.o uart.o -m68010 -g -nostart files -Wl,--script=ram.ld,-Map=CPU.map,--allow-multiple-definition -o CPU.elf c:/msys64/home/user/toolchain68k/toolchain-m68k-elf-current/bin/../lib/gcc/m68k- elf/9.2.0/../../../../m68k-elf/bin/ld.exe: section .text.startup LMA [0000000000 012a00,0000000000012a41] overlaps section .data LMA [0000000000012a00,0000000000 012f0f] collect2.exe: error: ld returned 1 exit status make: *** [CPU.elf] Error 1

I left the ram.ld script pretty much alone, I did change the memory locations and I even tried increasing the size to the max size of my system, but it didnt change anything.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/haarer/toolchain68k/issues/2

-- Gruß, Alexander

[thetechknight]

ok, I will give it a read. I also noticed that the same .o files get added 2, sometimes 3 times in the binary. for example crt0.o is added twice, back to back. So when I check the bin file in a disassembler, sure enough, theres two copies of the subroutines. Theres also 2 copies of the vector table. Its weird. I am using the ram.ld build script.

[thetechknight]

Nope, doesnt work at all.

It explodes when I take these out: PROVIDE (stack = 0x101000); PROVIDE (heap_limit = stack); PROVIDE (start = text_start); PROVIDE (__vec_start = ram_vec_start);

Bunch of undefined errors in vector.o, etc.

[thetechknight]

I think I figured it out. there is a bug in your 68k_example.

In your linker, you have STARTUP and INPUT for both the crt0 as well as vector, but at the same time, the makefile ALSO has those in the build string. So, its building those 2 .o files and linking them in twice.

Still doesnt fix the overlap issue, but it does fix the issue of having o files linked in twice.

[thetechknight]

Changing .data : AT ( ADDR( .text ) + SIZEOF( .text ) )

in your ram.ld file to simply .data : fixed the issue. Not sure what the other parts of it are doing?

[haarer]

Thanks for analysing, i'll look into that when i'm back.

There ist also an other example, using a different linker Script (bcc.ld) which comes with gcc. It is also easier in terms of startup files, if i remember correctly.

Am 7. Dezember 2019 20:55:50 MEZ schrieb mbates14 notifications@github.com:

Changing .data : AT ( ADDR( .text ) + SIZEOF( .text ) )

in your ram.ld file to simply .data : fixed the issue. Not sure what the other parts of it are doing?

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/haarer/toolchain68k/issues/2#issuecomment-562881254

-- Gruß, Alexander

[thetechknight]

Ok, let me know. Not sure what repercussions omitting that AT + SIZEOF thing does. But it compiled without an error.

Thanks

[thetechknight]

Actually, removing that line puts the .data at that physical location so it makes the File 1MB long. Whoops.

From doing further reading, it turns out when optimizing GCC, it puts main outside .text into its own subsection which is why its breaking, since the linker script doesnt deal with subsections, so data is clobbering on top of .text.startup (main) subsection... Not sure how to fix that.

[haarer]

If you know the subsection name, you could include it explicitly, or perhaps use the wildcards .

The webpage has examples for that.

If you need to deal with eproms and perhaps preinitialized Data that needs to be copied to RAM, the Page has an example as Well: http://www.scoberlin.de/content/media/http/informatik/gcc_docs/ld_toc.html#TOC32

Am 7. Dezember 2019 22:39:43 MEZ schrieb mbates14 notifications@github.com:

Actually, removing that line puts the .data at that physical location so it makes the File 1MB long. Whoops.

From doing further reading, it turns out when optimizing GCC, it puts main outside .text into its own subsection which is why its breaking, since the linker script doesnt deal with subsections, so data is clobbering on top of .text.startup (main) subsection... Not sure how to fix that.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/haarer/toolchain68k/issues/2#issuecomment-562889066

-- Gruß, Alexander

[thetechknight]

Yea I was doing some research on it last night. Eventually I disabled subsections in the makefile. I could add it in the linker I guess.

The other side-effect of turning on optimization, is now I am getting printf printing the string twice. instead of once. I cant figure that out either, Odd...