Who's Online |
70 user(s) are online ( 54 user(s) are browsing Forums)
Members: 0
Guests: 70
more...
|
|
Headlines |
-
amystromwifiswitch.lha - utility/misc
Mar 29, 2023
-
nvme_driver.lha - driver/storage
Mar 26, 2023
-
amiarcadia.lha - emulation/gamesystem
Mar 26, 2023
-
animwebconverter.lha - graphics/misc
Mar 27, 2023
-
vanillara.lha - game/strategy
Mar 25, 2023
-
vanillatd.lha - game/strategy
Mar 25, 2023
-
amitube.lha - video/play
Mar 25, 2023
-
amissl-sdk.lha - development/misc
Mar 23, 2023
-
unext.lha - game/platform
Mar 23, 2023
-
mce.lha - game/utility
Mar 23, 2023
|
|
|
|
Re: The ADTOOLS thread
|
|
Just popping in 
|
@afxgroup
Your definitely right a newer binutils is what we need.
|
|
|
|
Re: The ADTOOLS thread
|
|
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.
|
|
|
|
Re: The ADTOOLS thread
|
|
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"
|
|
|
|
Re: Qt 6 progress
|
|
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.
|
|
|
|
Re: Qt 6 progress
|
|
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.
|
|
|
|
Re: Qt 6 progress
|
|
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 
|
|
|
|
Re: Qt 6 progress
|
|
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
|
|
|
|
Re: Qt 6 progress
|
|
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....
|
|
|
|
Re: Qt 6 progress
|
|
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.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/23 10:08
#10
|
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.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/22 20:12
#11
|
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?
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/22 17:17
#12
|
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.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/22 14:49
#13
|
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.cSo 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?
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/12 16:15
#14
|
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?
|
|
|
|
Re: Binutils port
|
Posted on: 1/11 15:23
#15
|
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.
|
|
|
|
Re: Binutils port
|
Posted on: 1/11 12:04
#16
|
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?
|
|
|
|
Re: Qt 6 progress
|
|
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.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 1/10 18:21
#18
|
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.
|
|
|
|
Re: Binutils port
|
Posted on: 1/10 14:39
#19
|
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: 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.
|
|
|
|
Binutils port
|
Posted on: 1/10 11:16
#20
|
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 on github. 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.
|
|
|
|