C compilers?

[Chilly Willy]

On 9/5/2019 at 10:14 AM, SCPCD said:

Hi !

 

I'm currently working on an C app with multiple files and I'm using "m68k-atari-mint-gcc".

It works great, but after adding some more variables, I got an issue where a variable in BSS segment are not aligned with what I need :

 

When using gcc, all variable are aligned in word boundaries, but for specific ones, I need those to be longword aligned.

I tried to add " __attribute__((aligned(4)))" to have something as "u8_t toto[1024]  __attribute__((aligned(4)))" but at build time gcc give me the warning "warning: alignment of 'toto' is greater than maximum object file alignment.  Using 2 [enabled by default]" and finally the variable is not aligned to a longword.

 

Why gcc don't take account of the attribute and how to resolve the issue ?

 

Thanks

 

 

You align arrays in gcc (m68k) like this

 

unsigned char __attribute__((aligned(16))) rom_hdr[256];

 

This has always worked fine for me.

 

[swapd0]

There's something wrong with my linker setup? I've some weird issues, I have an assert to check if I call to build the sprite list several times in a frame (sort of), the flag it's defined as static int16_t _building = 0; (It's data or bss?) but if I write a couple lines of code (actually two in a particle system) the assert it's triggered at the start of the execution(The init code builds an empty sprite list) !!!! WTF!? 

 

Or maybe there's something wrong/mismatch with the compiler flags for the game and the library?

	ENTRY(_start)

	MEMORY {
	       rom (rx) : org = 0x802000, len = 2M-0x2000
	       ram (rx) : org = 0x004000, len = 2M-0x4000
	}

	stack_top = ORIGIN(ram)-4;
	_end = ADDR(.heap);

	SECTIONS {
	   .text : {
	      KEEP(*(.init))
	      *boot.o(.init)
	      *.o(.text)
	      . = ALIGN(4);
	     /* needed for cstartup */
	      __section_init = .;
	   } > ram

	   .data ALIGN(8) : {
	      *(.data)
	      . = ALIGN(8);
	   } > ram

	   .bss ALIGN(8) : {
	      *(.bss)
	      . = ALIGN(8);
	   } > ram

	   .heap ALIGN(32) : {
	   } > ram
	}

 

Edited March 17, 2020 by swapd0

[42bs]

Check the map file if there is also a COMMON section. Your startup code might not initialize it.

[swapd0]

I've been looking at the makefiles and I think that it's the -flto flag (link time optimization)(again...), I removed it from the library and from Classic Kong long time ago, but this game it's using it...

 

Copy&paste bug

Edited March 17, 2020 by swapd0

[ggn]

-flto is such a pain. Because of that I doubt rln will ever fully support linking with ELF objects. I mean, we can add ELF object files easily but if people link against any gcc compiled library which is compiled with -flto then who knows how much work it would need. My estimation is that we essentially would be rewriting ld, including bugs and undocumented stuff.

[swapd0]

I'm assuming that gcc leaves d0/d1 and a0/a1 free, so I don't need to save them in my assembly routines, it's this true?

 

[ggn]

At least versions 4 onward do that, yes. If you want a particular file to not touch more registers you can compile the file with, for example, -fcall-used-d2.

[swapd0]

On 11/28/2018 at 6:29 PM, ggn said:

Also I totally forgot I have packaged up gcc 8.2 for macs (built on El Capitan) here: http://d-bug.mooo.com/various/brownart.tar.bz2. So worst case you could give this a shot!

IIRC I've this version installed with a very strip down version of the C libraries, and if I've a float in the sources I get a lot of linker errors (undefined references to ___addsf3, ___muldf3, etc), where can I find the source of the floating point library?

 

I know that floating point it's very slow but it's better to have project running and then make changes to remove the floating point part.

 

[ggn]

Oh, floats. Well, in the past I've used https://github.com/ggnkua/pml-bigbrownbuild which is still not built using the build script. I think this repo is kind of patched up to work with newer gas format.

 

If memory serves correct, just get this repo, cd to 'pmlsrc', edit 'Makefile.16' and 'Makefile.32' to the right paths. Then type 'make -f Makefile.16', copy the .a file somewhere, then 'make -f Makefile.32'. I cannot remember which of the two I used in the past but at least one should work.

[swapd0]

Compiled but I still have the same errors, I've tried both libraries, I've seen that the library defines functions like cadd and cmult but I got undefined references to ___addsf3, ___multdf3, etc At least the cos, sin, round, errors are fixed.

 

 

Edited October 4, 2020 by swapd0

[dilinger]

17 minutes ago, swapd0 said:

I got undefined references to ___addsf3, ___multdf3, etc

You can find them in the gcc library (libgcc.a) directory available with m68k gcc.

[swapd0]

3 minutes ago, dilinger said:

You can find them in the gcc library (libgcc.a) directory available with m68k gcc.

Yes!!! I've included -lgcc and "all" linkers errors are gone.

[ggn]

15 hours ago, swapd0 said:

Yes!!! I've included -lgcc and "all" linkers errors are gone.

Ship it!

[swapd0]

I'm trying to compile some cpp code but I got liker errors, it works fine with C code.

 

This is the code, if I don't alloc X into the heap it works, but fails with the new operator.

class X
{
public:
    int a;
    int b;
};

int main(int argc, char **argv)
{
    X *x = new X;
    x->a = 100;
    return 0;
}

And here the weird link error. Where is _Znwm defined?

 

m68k-ataribrownart-elf-g++ -c -m68000 -Ofast -fomit-frame-pointer -fstrict-aliasing -fno-zero-initialized-in-bss -fcaller-saves -flto -ffunction-sections -fdata-sections -fleading-underscore -D__JAGUAR__ -D__M68000__ -Wall -o obj/main.o main.cpp
m68k-ataribrownart-elf-g++ -L/opt/local/bin/gcc68k/m68k-ataribrownart-elf/lib/m68000 -L/Users/Shared/apps/Jaguar/projects/lib -o out.elf  /opt/local/bin/gcc68k/lib/libcxx-jaguar/boot.o /opt/local/bin/gcc68k/lib/libcxx-jaguar/brownboot.o /opt/local/bin/gcc68k/lib/libcxx-jaguar/browncrti.o /opt/local/bin/gcc68k/lib/libcxx-jaguar/browncrt++.o /opt/local/bin/gcc68k/lib/libcxx-jaguar/zerolibc.o /opt/local/bin/gcc68k/lib/libcxx-jaguar/zerocrtfini.o /opt/local/bin/gcc68k/lib/libcxx-jaguar/vsnprint.o /opt/local/bin/gcc68k/lib/libcxx-jaguar/tinyalloc.o /opt/local/bin/gcc68k/lib/libcxx-jaguar/skunk.o \
	obj/main.o obj/gpu.o -lkatu -nostartfiles -nostdlib -Wl,-T,jag.ld,-Map,out.map -m68000 -Ofast -fomit-frame-pointer -fstrict-aliasing -fno-zero-initialized-in-bss -fcaller-saves -flto -ffunction-sections -fdata-sections -fleading-underscore  /opt/local/bin/gcc68k/lib/libcxx-jaguar/browncrtn.o
/var/folders/2g/phns652128s1650l3ck_1xbc0000gn/T//ccsrY2mK.ltrans0.ltrans.o: In function `_main':
<artificial>:(.text.startup.main+0x6): undefined reference to `__Znwm'
collect2: error: ld returned 1 exit status
make: *** [out.elf] Error 1

 

I used a modified version of the files found here.

https://github.com/ggnkua/bigbrownbuild-git/tree/master/barebones

 

 

[42bs]

See https://stackoverflow.com/questions/14301899/llinking-znam-and-znwm

 

Do you really want to use new/delete? If yes, you need a heap.

 

For the start you may provide sbrk(), malloc() and free()..

I'd try linking w/o the -nostartfiles, -nostdlib options for a start.

 

[swapd0]

31 minutes ago, 42bs said:

See https://stackoverflow.com/questions/14301899/llinking-znam-and-znwm

 

Do you really want to use new/delete? If yes, you need a heap.

 

 

No, but I don't wanna touch the code. ?

 

I'll make a call to malloc/free into _Znwm, _ZdlPvm and see if it works...