@afxgroup

Your definitely right a newer binutils is what we need.

@kas1e

I didn't stop exactly. I just very limited time currently. I even haven't cached up with QT6 thread where i left a couple of weeks ago. I think it will even take some couple of week before i return to binutils.

@joerg

I think rjd324 is even using the unreleased improved elf.library from elfpipe. And so it can even work without ctors/dtors, because as long i understood eflpipe moved the constructor/destructor handling into the elf.library. This further means, depending on how much effort elfpipe put into it, even newer mechanism can be supported by the elf.library. And additional the handling is decoupled from the used clib, it doesn't need anymore to provide __shlib_call_constructors() and __shlib_call_destructors() function.

As a last step to have the sobjs support not spread other the elf.library and the clib, would be to get rid of shcrtbegin/shcrtend files. If that could be reached sobj support on Amiga OS 4 would relay solely on OS parts. And clibs would become more "common"

@elfpipe

Quote:

Because of limited time currently. I only flow everything very light to not get lost to much. But I think this issue is somewhere binutils. At least I think I read somewhere that the linker constructs/has to construct the array. So that it works if the code only has the start pointer.

@elfpipe

Just out of curiosity, TLS (ThreadLocalStorage) isn't required/needed by QT 6?

@joerg

I don't really know, but my personal feeling is that binutils are more broken currently as the gcc, compared to the old working gcc/binutils version.

@elfpipe

That's great progress. Nothing is stopping you to continue with QT6, or?

I think the solution from you performing de/constructors resolving in the elf library, without we need for the __shlib_call_de-/constructors in the c library is right solution. With this solution sobjs can be realized transparent to the used c library.

BTW, i ruined my setup with misspelled entry in the Kicklayout file, without having a USB rescue stick , and the 4.1 FE iso has no recent version of the gfx driver, .... But i can boot again. Now i have only somehow a corrupted filesystem

@joerg

That is what I intended to do. But I played around with my amiga and now I cannot but anymore. need to recover it somehow before I can continue

@elfpipe

Quote:

Of course, It it wouldn't make sense to stop now. After having digging around in executable and sobjs etc. I starting to dram about elfs and dwarfs
But my "free" time will be limited the next weeks/month, but i will try to keep up and investigate further.

Quote:

But that is a lead i can follow....

@elfpipe

Sorry, I can‘t, because have no access to the newlib sources. I wish someone have access and could enlighten us.

@joerg

thanks. I thought github adtools is a one-to-one copy/clone of the sourceforge repo.

@elfpipe @afxgroup ....

I found where the __shlib_call_de-/constructors are "defined". they are part of the newlib c library and only present in the shcrtbegin.o file.

As with my experience during digging around in this topic, the shobjs support on OS4 is an custom defined solution, with interaction between the elf.library and the newlib. Or, you can name it even a none standard implementation. And as I see it newlib is the only c lib having these glue functions. So any other c lib implementation who wants to support the creation of shobjs needs to supply these glue function, to have it work with the current available tools. Thus currently my guess is, that the glue functions of the newlib has bug, which misses to call all presents constructor.

But going forward I'm with elfpipe, that custom glue code/logic in the shobjs should be avoided. And the dynamic linker (elf.library) should implement the various strategy calling de-/constructors, depending what is present in the so file. As long i oversee the elf standard and the amiga additions we have/cloud support the flowing variants:

a) The newlib __shlib_call_de-/constructors variant for backwards compatibility. Might be that it is not needed, because all shjobs file already have all information to support the next variant:
b) The .ctor/.dtor variant, which is elf standard. But even that is replaced with a newer variant:
c) The .init_array variant, which is "latest" shit on the elf side.

Going for the latest variants, would be really coll, because the needed modification to binutils would be minimal.

@joerg

You are properly right. I couldn’t find the sources/patches regarding gcc 2/3. Do you know where they are?

@elfpipe

The link you posted, I have already found on my quest, but thanks anyway.

Thinking about the problem, the current state seems to be that InitSHLibs don't handle de-/constructor in anyway. It just delegates the handling to the __shlib_call_de-/constructors, which is a custom Amiga solution. Furthermore who/where is responsible for creating the __shlib_call_de-/constructors stubs/glue code is unknown.

Thus handling the calling of de-/constructor in the elf.library seems to the better solution and more in common how elf dynamic loading is handled on other OSes. Additional the elf.library could implement de-/constructor handling via dtor/ctor and even support for the newer variants, like init_array. So the sobjs/binutils could evolve to be more standard alike.
Eflpipe as long i know, you have access to the sources of the elf.library, so it is in your hands.


@joerg

I tried to compile the issue 139 from adtools with GCC 4, which failed with an error regarding the de/constructor attribute. I didn't followed that way any further. I switch the gcc to 11.

Bur it's good to know that in older gcc setups everything worked as expected, because currently I only focus on GCC 11 and latest ported binutils/latest binutils from GNU.

I tried to get a picture how constructors/destructors call works on AmigaOS 4 with sobjs.
I now more or less tried to understand what the method __shlib_call_constructors and __shlib_call_destructors perform in sobjs.
As long i see it they implement loops calling methdos from the .ctors / .dtors section. Similar to the methods
init/fini from afxgroup clib2 in the file crtbegin.c

So long so good. If a program needs sobjs, the used clib takes care to to call InitSHLibs from the elf library, which again
calls __shlib_call_constructors/ __shlib_call_destructors. Afxgroup clib2 does is like this. Because i can only sneak
in the clib from afxgroup, this is a guess for newlib and the default clib2.

My conclusion is now regarding the 139 bug is either the __shlib_call_constructors implementation is buggy, which i cannot confirm,
(BWT does anyone know where the code for this methods are generated) or the used clib library had the great idea to not use the
InitSHLibs from elf.library, but instead to implement a own process to call constructors/desctructors. Actually it can even be that
InitSHLibs is buggy and all clib calls it.

So I compiled the 139 test case with newlib and the default clib2 from the SDK. Using newlib behaves as reported, faulty. Using clib2
the dynamic compilation fails with an DSI during staring.

Thus can anyone compile the example with the clib2 from afxgroup and report back the result from running the static and dynamic version?

@joerg

Quote:

Good idea! But i couldn't figure out how to call vbcc to generate a sobj with/or to let him
produce PIC code. Anyone know how to do it?

@kas1e

Quote:

That i thought at first too, but that makes no sense. If if on other OS if you strip-all, you get in 99% of use case
a useless binary. That's why they have --strip-unneeded, i think.

Maybe someone knows a good small program, which can be ported, and makes use of some kind of stripping.

@walkero

Maybe answering some of my question would help Anyone else is even encourage to answer if he has insight.

And here comes a question regarding objcopy and the strip options. For amiga elf objcopy has been modified
in regards how --strip-all works. It doesn't strip everything. It keeps mainly the symbols _SDA_BASE_, _start,
_amigaos4_, and some other symbols under some circumstances. This is very specific for amiga, on all other
platforms (as far i have looked into it), the --strip-all option is taken as it is. It removes all symbols,
regardless if it is smart to do so or not.

What I don't understand, why hasn't that functionality been implemented under the --strip-unneeded option,
because putting the behavior under that option seems for me to be more logical. So is there any historical
reason why it is, like it is, or did it just happen to be so, without any deeper thoughts?

@afxgroup, @elfpipe

Quote:

Well I cannot be 100% sure, because I have no insight in how sobjs loading is implemented. Maybe elfpipe can confirm it/look into it.

But based upon the documentation of the InitSHLibs method of the elf.library and that the failing test still somehow calls one
constructor, but both destructors, I conclude that both methods __shlib_call_constructors and __shlib_call_destructors gets called.
Furthermore, because they do in the example pretty much the same, they should look a like. But for me the ppc dump,
don't like similar enough. I think i have do analyses the ppc code.

Regarding the constructor issue. As long i understand it is that the elf.library during lodding the libf.so calls the __shlib_call_constructors method, which should call the constructors of the shared object library. From the example given here, it looks like that the test_dyn laods the libf.so and that the gets __shlib_call_constructors. For me it looks like that the implementation of __shlib_call_constructors might be buggy in calling all present constructors:



For me ppc assembler is still hard to read, but might it be that it is not correct. Even in regards that the deconstructors works and looks like this:



I would have think that they should look more like each other, because they actually do nearly the same stuff.

Quote:

First i thought so too, but somewhere in between they made a quiet mayor changes. So I concluded,
why bother with steps by steps, instead go to the head.

The biggest change is that they changed their inner APIs. In most cases it isn't that difficult
to adapt, as long I understand the stuff actually should do.

One major change is that actually the elf32-amigaos.c file isn't needed anymore. The needed
changes (which aren't that much) can now be completed embedded in elf32-ppp.c. For some changes
I'm really wondering why they are actually needed.

But currently my main issues are to get objcopy.c adopted to the new API. The stuff added to
objcopy.c seem to be related to the feature strip unneeded relocations. But it is hard to reverse
engineer what defines unneeded relocations on the amiga elf platform?

Quote:

I will take a look, but the first aim isn't to port gdb to. My repository is anmed that way,
because the upstream repo, has that name too.

I'm started to apply all the patches from the binutils adtools ports to the current main development
trunk of the binutils. For that I setup a temp. repository ongithub.
I tried to only take over all changes that are needed for AmigaOS ELF. Omitting Morphos, AROS, AmigaOS
Hunk.
Because there are parts which changed a lot I had more or less manually apply all patches. Some patches
weren't needed any more, others were straight forward, and others hat to be adapted in that way, that they
merely are recognizable anymore.

Id doesn't compile yet, mainly i have issues to adapt the apaches for obycopy.c and the build system for
the gas part. Maybe someone can help?

The flowing patches haven't been yet manually applied, because I'm unsure if they are really still needed:

* 0010-Fix-Wimplicit-fallthrough-warnings.patch

Mainly because the most of them just change the comment, but some even add break statement, which might have
unwanted side effects,

* 0013-Don-t-emit-dynamic-relocations-for-data-symbols.patch

I'm unable to match it with the new structure of the binutils.