Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
70 user(s) are online (54 user(s) are browsing Forums)

Members: 0
Guests: 70

more...

Headlines

Forum Index


Board index » All Posts (MigthyMax)




Re: The ADTOOLS thread
Just popping in
Just popping in


@afxgroup

Your definitely right a newer binutils is what we need.

Go to top


Re: The ADTOOLS thread
Just popping in
Just popping in


@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.

Go to top


Re: The ADTOOLS thread
Just popping in
Just popping in


@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"

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@elfpipe

Quote:
So the problem seems to be, that the __CTOR_LIST__ entry at the beginning of shcrtbegin.c is not guaranteed to be inserted at the beginning of the section.


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.

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@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.

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@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

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@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

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@elfpipe

Quote:
This is good to know. There is definitely something wrong with the calling order, so now the question is just where. @MightyMax : Are you up for this?


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:

Is it possible that someone could assist in analyzing the readelf output to try and figure out, which kind of relocation is missing?


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

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@elfpipe

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

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@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.

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@joerg

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

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@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.

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


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?

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@joerg

Quote:
Another option to check what's broken in GCC and/or binutils is using VBCC and
it's vlink instead, and compare the generated ELF binaries and constructor/destructor
codes in them.
Unlike GCC/binutils VBCC/vlink should still work correctly.


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?

Go to top


Re: Binutils port
Just popping in
Just popping in


@kas1e

Quote:
I can't say for 100% sure why they choose the "--strip" way, but i think that for the reason to be “ok” with
all the makefiles and stuff by default, as most of the time they use "strip" in linux and other OSes. IMHO, it all
done just for “Easy porting”.


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.

Go to top


Re: Binutils port
Just popping in
Just popping in


@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?

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@afxgroup, @elfpipe

Quote:
So can you confirm that elf.library calls __shlib_call_constructors and __shlib_call_destructors when load shared objects thru InitSHLibs?


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.

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


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:

100003e8 __shlib_call_constructors:
100003e8:    94 21 ff f0     stwu    r1,-16(r1)
100003ec:    7c 08 02 a6     mflr    r0
100003f0
:    42 9f 00 05     bcl     20,4*cr7+so,100003f4 __shlib_call_constructors+0xc
100003f4
:    39 40 00 00     li      r10,0
100003f8
:    93 c1 00 08     stw     r30,8(r1)
100003fc:    7f c8 02 a6     mflr    r30
10000400
:    90 01 00 14     stw     r0,20(r1)
10000404:    80 1e ff f0     lwz     r0,-16(r30)
10000408:    7f c0 f2 14     add     r30,r0,r30
1000040c
:    80 de 80 00     lwz     r6,-32768(r30)
10000410:    7c c8 33 78     mr      r8,r6
10000414
:    48 00 00 08     b       1000041c __shlib_call_constructors+0x34
10000418
:    7c ea 3b 78     mr      r10,r7
1000041c
:    85 28 00 04     lwzu    r9,4(r8)
10000420:    38 ea 00 01     addi    r7,r10,1
10000424
:    2f 89 00 00     cmpwi   cr7,r9,0
10000428
:    40 9e ff f0     bne     cr7,10000418 __shlib_call_constructors+0x30
1000042c
:    2f 8a 00 00     cmpwi   cr7,r10,0
10000430
:    41 9e 00 24     beq     cr7,10000454 __shlib_call_constructors+0x6c
10000434
:    55 4a 10 3a     slwi    r10,r10,2
10000438
:    80 01 00 14     lwz     r0,20(r1)
1000043c:    7d 26 50 2e     lwzx    r9,r6,r10
10000440
:    83 c1 00 08     lwz     r30,8(r1)
10000444:    7c 08 03 a6     mtlr    r0
10000448
:    38 21 00 10     addi    r1,r1,16
1000044c
:    7d 29 03 a6     mtctr   r9
10000450
:    4e 80 04 20     bctr
10000454
:    80 01 00 14     lwz     r0,20(r1)
10000458:    83 c1 00 08     lwz     r30,8(r1)
1000045c:    38 21 00 10     addi    r1,r1,16
10000460
:    7c 08 03 a6     mtlr    r0
10000464
:    4e 80 00 20     blr
10000468
:    00 01 9b dc     .long 0x19bdc


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:

1000046c __shlib_call_destructors:
1000046c:    94 21 ff f0     stwu    r1,-16(r1)
10000470:    7c 08 02 a6     mflr    r0
10000474
:    42 9f 00 05     bcl     20,4*cr7+so,10000478 __shlib_call_destructors+0xc
10000478
:    93 c1 00 08     stw     r30,8(r1)
1000047c:    7f c8 02 a6     mflr    r30
10000480
:    90 01 00 14     stw     r0,20(r1)
10000484:    80 1e ff f0     lwz     r0,-16(r30)
10000488:    93 e1 00 0c     stw     r31,12(r1)
1000048c:    7f c0 f2 14     add     r30,r0,r30
10000490
:    83 fe 80 04     lwz     r31,-32764(r30)
10000494:    81 3f 00 04     lwz     r9,4(r31)
10000498:    2f 89 00 00     cmpwi   cr7,r9,0
1000049c
:    41 9e 00 1c     beq     cr7,100004b8 __shlib_call_destructors+0x4c
100004a0
:    3b ff 00 04     addi    r31,r31,4
100004a4
:    7d 29 03 a6     mtctr   r9
100004a8
:    4e 80 04 21     bctrl
100004ac
:    85 3f 00 04     lwzu    r9,4(r31)
100004b0:    2f 89 00 00     cmpwi   cr7,r9,0
100004b4
:    40 9e ff f0     bne     cr7,100004a4 __shlib_call_destructors+0x38
100004b8
:    80 01 00 14     lwz     r0,20(r1)
100004bc:    83 c1 00 08     lwz     r30,8(r1)
100004c0:    83 e1 00 0c     lwz     r31,12(r1)
100004c4:    7c 08 03 a6     mtlr    r0
100004c8
:    38 21 00 10     addi    r1,r1,16
100004cc
:    4e 80 00 20     blr
100004d0
:    00 01 9b 6c     .long 0x19b6c


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

Go to top


Re: Binutils port
Just popping in
Just popping in


Quote:
Wouldn't it be easier to start with the adtools version and gradually update it to newer versions?


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:
ps. i see your repo called "binutils-gdb", just in case there is my attempt porting
newer GDB: https://github.com/kas1e/gdb


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.

Go to top


Binutils port
Just popping in
Just popping in


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.

Go to top



TopTop
(1) 2 3 4 ... 6 »




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project