ggn Posted December 13, 2018 Share Posted December 13, 2018 Other random thought: are you using link time optimisation (-flto)? This can seriously mess up the order of object files. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 13, 2018 Share Posted December 13, 2018 (edited) Other random thought: are you using link time optimisation (-flto)? This can seriously mess up the order of object files. Yes, I'm using -flto, I'll have a look later. Maybe the solution it's to write my elf to jag executable and put the jmp _start at the beginning. Doing the relocation at the jaguar it's "impossible" at development time, because I've the rom with the assets into a "filesystem" block at rom, and I upload the code at ram. ------------- Added ------------- Without -flto it gives a linker error, undefined reference to _malloc at zerolibc.cpp, although that's for C++. Edited December 13, 2018 by swapd0 Quote Link to comment Share on other sites More sharing options...
ggn Posted December 13, 2018 Share Posted December 13, 2018 Without -flto it gives a linker error, undefined reference to _malloc at zerolibc.cpp, although that's for C++. Did you rebuild everything from scratch without -flto? Both compiler and linker settings have to be in sync. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 13, 2018 Share Posted December 13, 2018 Did you rebuild everything from scratch without -flto? Both compiler and linker settings have to be in sync. Yes, I did a make clean, and removed all .o files at libcxx directory. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 14, 2018 Share Posted December 14, 2018 I've written a program to relocate the TOS file generated by brownout to the address 0x4000, for now it looks good. Now it's time to test it with a real program... Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 14, 2018 Share Posted December 14, 2018 Why my functions don't get exported when I compile some files into a static library? I'm using these parameters: CFLAGS = -Ofast -fomit-frame-pointer -fstrict-aliasing -fcaller-saves -flto -ffunction-sections -fdata-sections -fleading-underscore -fvisibility=default -Wall I've also tried to put extern or __attribute__ ((visibility ("default"))) at the beginning of the function but the function it's not exported. When I call nm -g libjaguar.a the only symbols that I get are from some assembler files, but no symbol from C code. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 14, 2018 Share Posted December 14, 2018 Fixed, just remove -flto flag Quote Link to comment Share on other sites More sharing options...
ggn Posted December 15, 2018 Share Posted December 15, 2018 One thing I'm puzzled over this approach is what would you do when you want to create a rom file where text+data won't be contiguous with the BSS - perhaps it would be best to modify brownout directly for this? Quote Link to comment Share on other sites More sharing options...
swapd0 Posted December 15, 2018 Share Posted December 15, 2018 I thought that BSS it's always at the end, first text, then data, and bss at the end. I think that I'm going to have some problems with mallocs, because they will ask to the OS for a memory chunk. Quote Link to comment Share on other sites More sharing options...
ggn Posted December 15, 2018 Share Posted December 15, 2018 Well, my thought was that you are going to run a binary that gcc/ld/whatever else outputted in ROM directly. Then your code and data will be at $802000, and the bss will have to be in main RAM. But if you plan to copy the binary from ROM to RAM and run it there, no problems. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 5, 2019 Share Posted February 5, 2019 (edited) Bump!!! I've compiled a sprite test with gcc and it "works"... I mean, it compiles and executes ok, but I had to define the following functions to avoid linker errors, and of course the program doesn't work properly. Where can I get a small free/malloc functions? I've been "googling" but I want a small and simple version. Also I don't know why I need the memset because it was defined in brownboot.s. void free(void *ptr) { skunk_print("free\n"); } void *malloc(size_t bytes) { skunk_print("malloc\n"); return 0; } void *calloc(size_t n, size_t bytes) { skunk_print("calloc\n"); return 0; } void *memcpy(void *dst, const void *src, size_t bytes) { skunk_print("memcpy\n"); return 0; } void* memset(void* dst, int v, size_t bytes) { skunk_print("memset\n"); return 0; } Edited February 5, 2019 by swapd0 Quote Link to comment Share on other sites More sharing options...
ggn Posted February 5, 2019 Share Posted February 5, 2019 Lately I've seen one person using https://github.com/thi-ng/tinyalloc 1 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted February 6, 2019 Share Posted February 6, 2019 Dynamic memory management isn't too difficult to code from scratch, you might benefit from a custom Jaguar specific written one also. If you are say allocating RAM for a bitmap or OP list you are going to want it correctly aligned in memory, using stock generic managers might make more work for you ensuring you request excess RAM and determine correct alignment within. If you wrote your own you could specify any alignment requirements in the request and have the system nicely return memory appropriate to your needs. Quote Link to comment Share on other sites More sharing options...
ggn Posted February 6, 2019 Share Posted February 6, 2019 Dynamic memory management isn't too difficult to code from scratch, you might benefit from a custom Jaguar specific written one also. If you are say allocating RAM for a bitmap or OP list you are going to want it correctly aligned in memory, using stock generic managers might make more work for you ensuring you request excess RAM and determine correct alignment within. If you wrote your own you could specify any alignment requirements in the request and have the system nicely return memory appropriate to your needs. From the page I linked: TA_ALIGN 8 Word size for pointer alignment TA_BASE 0x400 Address of tinyalloc control data structure TA_DEBUG undefined Trace debug information TA_DISABLE_COMPACT undefined Disable free block compaction TA_DISABLE_SPLIT undefined Disable free block splitting during re-alloc TA_HEAP_START 0x1010 Heap space start address TA_HEAP_LIMIT 0xffffff Heap space end address TA_HEAP_BLOCKS 256 Max. number of memory chunks TA_SPLIT_THRESH 16 Size threshold for splitting chunks I think all that pretty much covers what you said? 1 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted February 6, 2019 Share Posted February 6, 2019 Yeah, but... *sulks* Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 6, 2019 Share Posted February 6, 2019 It's not very complex but (for this) I prefer to use some already tested code than doing it by myself. I don't understand this. uint32_t *_op_objects = NULL; void init_sprites(int16_t lists, int16_t sprite_count) { video_off(); if ( _op_objects != NULL ) free(_op_objects); ... } free call it's executed, WTF!?!?! It's supposed to be initialised with NULL. Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted February 6, 2019 Share Posted February 6, 2019 Perhaps the compiler isn't setting the variable with NULL correctly? perhaps try manually setting it to NULL in code before calling init_sprites? see if that resolves it, will tell you if compiler is doing it correctly... Or something somewhere is overwriting that variable/populating it? Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 6, 2019 Share Posted February 6, 2019 (edited) Ok, I got the sprite test running (at last!!!!). The problem that I talked about it was because I set the HEAP_START just after the label __fini_array_end, that I was supposing that it was at the end of my program (wrong!!!!!). To fix this I've put the heap address at 1MB, it's a bad solution but at least I see that the compiler, and everything else works. I'm generating a TOS executable and then I relocate the program at 0x4000 and it works, to fix my crap solution I need to put the heap start address at the end of my program (text + data + bss), for now the only solution that I've is to change the relocation program to include the program size at the beginning, just after the first opcode (it's a jmp), then the ta_init() function will read this size to know the heap start address. Any better idea? Edited February 6, 2019 by swapd0 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted February 6, 2019 Share Posted February 6, 2019 Can you not define a label at the end of your program BSS and then use that as the heap location? For safety i'd make sure it's at least phrase aligned in RAM though. From what GGN showed earlier I suspect that if the heap is long aligned the malloc will not adjust it for alignment. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 6, 2019 Share Posted February 6, 2019 Don't worry, I've changed TA_ALIGN to have always 32bytes alignment for scaled bitmap objects. I'll try the label at the end... the problem it's to know which file it's the last one, or maybe I can create a file with a single label and link it the last one. Quote Link to comment Share on other sites More sharing options...
Sporadic Posted February 7, 2019 Share Posted February 7, 2019 Don't worry, I've changed TA_ALIGN to have always 32bytes alignment for scaled bitmap objects. I'll try the label at the end... the problem it's to know which file it's the last one, or maybe I can create a file with a single label and link it the last one. As mentioned above, from what I've seen, (I think it was Chequered Flag) there was a last.s which just included the relevant labels. That was the last thing linked to. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 7, 2019 Share Posted February 7, 2019 (edited) I've managed to include the heap bas at the end, you must put it as the last file but not into a symbol with all objects files. I've seen that there is a symbol (_end) that it's always the last one ... 00009764 B _end 00002168 T _end_sprites 0000143c T _exist_multitap 00000000 T _exit 000091cc b _exit_count 000082a8 b _exit_funcs 00003424 T _fade_palette 000004e2 t _fmtint 000090c0 b _frame_buffer 00006060 d _frame_metadata 000091b4 b _frame_sprite 00000ff8 T _free 00009760 B _heap_start ... Anyway, if I use _end or _heap_start + 32 (If I use _heap_start it doesn't work) as the start heap address I get an error from brownout. error: reference 0x00009764 points at an area not mapped by existing sections Edited February 7, 2019 by swapd0 Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 7, 2019 Share Posted February 7, 2019 Fixed. Quote Link to comment Share on other sites More sharing options...
swapd0 Posted February 7, 2019 Share Posted February 7, 2019 (edited) Cool, now it looks like I've the data miss-aligned, and I'm using a .phrase before the data. Here are the labels from the ELF file. 00006178 D _bmp2 00006280 D _bmp4 00006488 D _bmp8 And now the same labels from TOS file. _bmp2 D 00004b42 _bmp4 D 00004c4a _bmp8 D 00004e52 Edited February 7, 2019 by swapd0 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted February 8, 2019 Share Posted February 8, 2019 (edited) Take the address you get from end and make sure it is phrase aligned move.l #end,d0 add.l #8, d0 and.l #$fffffff8, d0 Will leave you with a phrase aligned address in d0 Edited February 8, 2019 by LinkoVitch Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.