ELF and shared objects headache

I'm getting crazy about my clib2 version and shared objects. and i don't know where to check. Basically i have this problem:

If i compile a program without shared objects everything works correctly.

If i compile with my patched GCC 10 that supports shared objects also for clib2 i have an undefined symbol when the elf.library try to call InitSHLibs.

I get 0x00000000 symbol not available.

The problem however is not in the shared object but in the crtbegin file that is the same with both shared and not shared objects since it is linked by gcc in the .c file.

Before you ask. Yes. I open Elf library and get the interface correctly in same file (crtbegin) and it is valid (otherwise it will crash also on not shared version)
I've also seen with Ranger that ELF library address i get is the same present in ranger.

All other libraries (Exec, DOS and more) are working correctly. For example i can use PrintF just before the crash and it prints the text correctly.

This is the code:

https://pastebin.com/aFr3AL11

Can you give me some hints?

@afxgroup

Ignore my previous idea, didn't spot the call to _main();

@afxgroup

Is it possible that the shared object in question has an unititialised __shlib_call_constructors function pointer?

But is not the shared object that crash. The crash happens in the exe file.

Basically the exe is just:



and if i compile it with:

ppc-amigaos-gcc -mcrt=clib2 print.c -o print

it works. Elf library is opened always in _start and InitSHLibs works correctly. Print file is linked against crtbegin.o and _start is in that file.

If i link it with:

ppc-amigaos-gcc -use-dynld -mcrt=clib2 print.c -o print

It crash. But the crash is not in the libc.so (that could have sense) but always in _start function

libc.so is the only shared object needed by that file has correctly both:

root@amigabuild2:/opt/libs/clib2# nm /usr/ppc-amigaos/SDK/clib2/lib/libc.so | grep __shl
10012a1c T __shlib_call_constructors
10012af4 T __shlib_call_destructors

Following your spot i've commented the constructors and destructors call inside those two methods but nothing change
I've also checked with snoopy but libc.so seems not opened at all.
The best would be too undersstand which symbol is trying to load but i don't know how to get it from grim reaper

@afxgroup

only libc.so not libgcc.so or other compiler related one?

What if you add DebugPrintF() into the __shlib_call_constructors function? You can tell if it's really called (stack traces are not always accurate / complete) and what it calls

and unitialised constructor functions?

Also up the kernel debug level to 5 or more and see whats on serial.

Also up the kernel debug level to 5 or more and see whats on serial.

The symbol was _init

i've reworked all the code and now everything works correctly.
However print the symbol that is not found would help a lot..

@afxgroup

How did you find out what the culprit was?

Maybe I can do something similar to find out why scummvm keeps crashing?

@afxgroup

Quote:

But it can't can it, because the stack trace value 0x00000000 has no symbol.

yes. but the Elf.library is trying to load "a symbol" that doesn't find. Which one? It is the same when you try to load a library needed by exe that is missing.

@afxgroup

Use serial and higher debug level to see what elf library is doing in detail, I'm not sure exactly how high > 5 as a guess.

But actually elf.library does report unresolved symbols in a requester, what is more likely happening here is that the symbol was a NULL value and so is jumping to 0x00000000 when 'called'. This crashes and is why you get the unhelpul stack trace.