Who's Online |
56 user(s) are online ( 42 user(s) are browsing Forums)
Members: 0
Guests: 56
more...
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/30 12:19
#141
|
Just can't stay away 
|
@joerg
I have now tested OWN Blastoise. It fails, but this is probably due to the missing dependencies in libstdc++.so mentioned by afxgroup.
@afxgroup
Do you have an idea how to fix this?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/28 17:51
#142
|
Just can't stay away
|
@joerg
The problem was, that the current implementation of __shlib_call_constructors would fail (= yield an incomplete array of constructors).
The reason for this problem is not 100% clear. But at least it has to do with the fact, that the .ctors (and .dtors) section would somehow not read completely.
Doing an implementation inside of elf.library does the job. This secures, that the section has the right size, that it is thoroughly relocated and that NULL pointers inside the section is handled.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/28 13:39
#143
|
Just can't stay away
|
Voila. Quote: 11.STICK:ctor_test> test_dyn
ctor
ctor2
foo
bar
f 123
main result 123
dtor2
dtor
11.STICK:ctor_test>
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/28 12:55
#144
|
Just can't stay away
|
@MigthyMax
Ach, nein... Hopefully it was not because of a system update.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/27 11:02
#145
|
Just can't stay away
|
@MigthyMax Maybe there is one more lead for you. Quote: Relocation section '.rela.ctors' at offset 0x174c contains 3 entries:
Offset Info Type Sym.Value Sym. Name + Addend
10011040 00002301 R_PPC_ADDR32 100006f4 _Z4ctorv + 0
1001103c 00002701 R_PPC_ADDR32 1000076c _Z5ctor2v + 0
10011038 00000801 R_PPC_ADDR32 10000520 .text + 388 And : Quote: [12] .ctors PROGBITS 10011034 001034 000014 00 WA 0 0 4
[13] .rela.ctors RELA 00000000 00174c 000024 0c 24 12 4 So a .rela.ctors is of size 36 (0x24), which equals three (3) entries. BUT when calling elf.library on the file, it outputs this : Quote: [Elf32_OpenReloc] section size = 24, entry size = 12
[Elf32_HandleReloc] Trying rela section 13 for reference section 12 So only two entries. The missing entry is now the static_initialization function, that calls foo() and bar(). Why is there a difference in size here?? I think elf.library gives the correct output, because it seems to just chuck out what's on disk. So the theory is, that readelf is 'inventing' entries as it goes along. But how?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/25 13:37
#146
|
Just can't stay away
|
@MightyMax No need to worry about the specs after all. It was simply a missread of the debug output on my behalf. Everything runs as it should. Now, I have this : Quote: 3.Work4.1:STICK/ctor_test> test_dyn
foo
bar
f 123
main result 123
3.Work4.1:STICK/ctor_test> So this is a step in the right direction. What I am doing is just to look up the .ctors section and treat it as an array of (uint32 *) pointers to functions. So far - as you can see - the foo and bar functions are called. These are coupled in a single entry through a caller function. The .ctors section is 12 bytes long (0x0c), so three pointers. The two others are NULL. I am guessing, that these other two represent the ctor() and ctor2() functions. Apparently there is an issue with incomplete relocation. Is it possible that someone could assist in analyzing the readelf output to try and figure out, which kind of relocation is missing? Thanks! EDIT: As a matter of fact, it is worth to take a look at this : Quote: 3.Work4.1:STICK/ctor_test> readelf -s lib.o
Symbol table '.symtab' contains 22 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS lib.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 SECTION LOCAL DEFAULT 5
6: 00000000 0 SECTION LOCAL DEFAULT 6
7: 000000a8 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115foo_ct
8: 000000a8 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115foo_ct
9: 00000000 1 OBJECT LOCAL DEFAULT 4 _ZN12_GLOBAL__N_1L18foo_c
10: 000000e0 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115bar_ct
11: 000000e0 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115bar_ct
12: 00000001 1 OBJECT LOCAL DEFAULT 4 _ZN12_GLOBAL__N_1L18bar_c
13: 00000184 128 FUNC LOCAL DEFAULT 1 _Z41__static_initializati
14: 00000204 60 FUNC LOCAL DEFAULT 1 _GLOBAL__sub_I_lib.c
15: 00000000 0 SECTION LOCAL DEFAULT 8
16: 00000000 0 SECTION LOCAL DEFAULT 10
17: 00000004 80 FUNC GLOBAL DEFAULT 1 _Z3foov
18: 00000000 0 NOTYPE GLOBAL DEFAULT UND puts
19: 00000058 80 FUNC GLOBAL DEFAULT 1 _Z3barv
20: 0000011c 100 FUNC GLOBAL DEFAULT 1 _Z1fi
21: 00000000 0 NOTYPE GLOBAL DEFAULT UND printf
3.Work4.1:STICK/ctor_test> Apparently the assembler has discared the ctor(2) and dtor(2) functions (they are included in the assembly). So probably this is the reason for the two vacant spaces in the .ctors section. Now - why would the assembler discard entries? The entries look almost exactly the same as the entries, that are included (in the assembly).
Edited by elfpipe on 2023/1/25 15:00:12
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/24 17:03
#147
|
Just can't stay away
|
@joerg Quote: IIRC there is no code inside crtend.o and shcrtend.o, they only include the end markers of the constuctor/destructor arrays, the code for calling the functions is in crtbegin.o and shcrtbegin.o.
If there is a problem with crtend.o or shcrtend.o it can only be because of a wrong linking order, i.e. something is wrong in the specs file of GCC. 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?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/24 16:00
#148
|
Just can't stay away
|
@MightyMax @joerg
I am presently in a bit of a mess. I have fixed InitSHLibs, so that it looks up the .ctors section. This required fixing a bug in LoadSegment. So far so good. But now I get a deadlock when the app closes down, and apparently (from what I can gather from Sashimi, before it dies) InitSHLibs is called AFTER CloseElf, which is probably the cause of the deadlock.
I cannot see any place, that this can happen from inside elf.library, so I gather the crtend.o or shcrtend.o is responsible. I cannot produce a disassembly any of of these. Can anyone else produce a disassembly?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/23 13:07
#149
|
Just can't stay away
|
@MigthyMax Quote: 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.
Can you post the source code for it here?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/23 12:56
#150
|
Just can't stay away
|
|
|
|
|
|
|
Re: libpng.so 14 there is a download link, thanks
|
Posted on: 2023/1/22 18:18
#151
|
Just can't stay away
|
@white
I only have 12 and 16. Not sure, where this dependency has sneaked in.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/22 15:04
#152
|
Just can't stay away
|
@MigthyMax InitSHLibs calls __shlib_call_constructors. Well, we can conclude, that here again the amiga is trying to do a non-standard solution, that doesn't work. I would say, that the correct solution would be to scrap the __shlib_call_constructors function and do construction by looking directly at the .ctors and .dtors sections from within elf.library. What do you think? Look here : https://maskray.me/blog/2021-11-07-init-ctors-init-array
|
|
|
|
|
|
Re: libpng.so 14 there is a download link, thanks
|
Posted on: 2023/1/21 10:58
#153
|
Just can't stay away
|
@white
I am glad to know, that the qt browsers work. Currently, as you might know, I have shifted focus from Qt4 to Qt6, and so there is not going to be more work done on the Qt4 stuff.
I can see, if I have the correct libpng on my machine. If I do, I will post a link here.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/15 12:09
#154
|
Just can't stay away
|
@joerg
I misspoke. The 'WebKit' I am refering to is the Qt wrapper around chrome. The build system here is very complex, and the less I have to mess with it, the better. The older webkit modules from previous Qt versions was no problem.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/14 15:48
#155
|
Just can't stay away
|
@Georg
You are completely right, and that was my first consideration. I originally planned to do Qt6 with static linking only.
BUT meeting the requirements of software, I want to build, changed my mind. I want to build qtcreator and webkit, and those build systems don't work with attempted static linking.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/11 15:37
#156
|
Just can't stay away
|
@MigthyMax 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. From first view, it looks like the constructors are called. Also your note, that some are called while others not is valid. I could construct a test to 100% verify, that it is the case. EDIT: Maybe the file binutils/ld/emultempl/amigaos.em is a possible target for out search?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/9 14:22
#157
|
Just can't stay away
|
@MigthyMax
Removing the '!' would give zero to 'world'. But I don't think this is the right solution. I think it is best to keep the binutils code as close to the original as possible. I trust it. Instead I suggest to adhere to the workflow, that is maintained and hinted at here. This would mean to ensure pointer equality in the cases, where st_value is non-zero, and that is exactly, what my solution does.
Edited by elfpipe on 2023/1/9 15:36:03
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/8 18:35
#158
|
Just can't stay away
|
@elfpipe A reply to myself. After consolidating the binutils 2.40 source, I have found this : Quote: if (!local_undefweak
&& !h->def_regular
&& (h->plt.offset != (bfd_vma) -1
|| eh->plt_got.offset != (bfd_vma) -1))
{
/* Mark the symbol as undefined, rather than as defined in
the .plt section. Leave the value if there were any
relocations where pointer equality matters (this is a clue
for the dynamic linker, to make function pointer
comparisons work between an application and shared
library), otherwise set it to zero. If a function is only
called from a binary, there is no need to slow down
shared libraries because of that. */
sym->st_shndx = SHN_UNDEF;
if (!h->pointer_equality_needed)
sym->st_value = 0;
} The important part is the comment. As stated, the binary loader (elf.library) needs to do an active comparison, when the value is non-zero. When zero, it just performs a lookup. In the current elf.library implementation, the easiest way of meeting this requirement, is to do a default lookup, which will always result in pointer equality. Since the .plt entry is private to the main app (or the specific shared object), there is no way of having pointer equality, when the entry points to the .plt entry. And the only known cases of a non-zero st_value are the ones, where st_value points to .plt. Please discuss.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/8 16:36
#159
|
Just can't stay away
|
@MigthyMax Actually, when looking at the original non-amiga text (as found in the patches) :
if (!h->pointer_equality_needed)
- sym->st_value = 0;
This is a bit mysterious. From my current perspective, this looks like a bug. The cases, that require pointer equality, are exactly the cases, where we need the st_value parameter to be zero. So this might be just a case of a '!' inserted in the wrong place. It will be interesting to know, what the updated binutils source says in this place.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/8 14:10
#160
|
Just can't stay away
|
@MigthyMax Quote: I won't go for the general way to perform a lookup. As the ABI states, it should only be made
if the value of the symbol is zero and a UNDEF function. Well, since the amigaos is already performing non-standard compared to the ABI, I think the argument could go either way. One could even argue, that the .plt stubs are obsolete, since they introduce no added functioning, but only helps to clutter the concept of linking. I am not sure, if there is some argument from cyber safety, that necessitates a .plt section. But from a functioning point of view, it is definitely unnecessary. IF we are to implement the ABI text and allow for linking using the st_value attribute for UNDEF entries, then we still need to figure out, why the 'world' symbol comes out non-zero in the example. Simply uncommenting the line with st_value = 0 doesn't solve that part of the problem.
|
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
