Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
50 user(s) are online (35 user(s) are browsing Forums)

Members: 0
Guests: 50

more...

Headlines

 
  Register To Post  

« 1 ... 10 11 12 (13) 14 15 16 ... 20 »
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information

Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@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?

Go to top
Re: Qt 6 progress
Just popping in
Just popping in


See User information
@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 can't stay away
Just can't stay away


See User information
@afxgroup
Quote:
But the constructors doesn't seems to be called. Or maybe libstdc++.so constructors are called early (before the libc constructors) and so I get a DSI
Maybe it's not related at all, but check https://sourceforge.net/p/adtools/bugs/1/ , there was a problem with a wrong linking order with clib2 as well.

Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@MigthyMax
Quote:
Sorry, I can‘t, because have no access to the newlib sources. I wish someone have access and could enlighten us.
shcrtbegin.o is very simple code, it should be no problem to understand what does by disassembling it.


Edited by joerg on 2023/1/24 5:23:40
Go to top
Re: Qt 6 progress
Amigans Defender
Amigans Defender


See User information
@joerg

mmm.. I don't know. In that bug the linking was static. In this case it is dynamic and instead of calling _init in .so file, it calls _init in the exe file that is causing the crash

i'm really tired...
Go to top
Re: Qt 6 progress
Amigans Defender
Amigans Defender


See User information
Well, reading https://forum.hyperion-entertainment.com/viewtopic.php?t=3743 it is possible (I hope) I found the problem. libstdc++.so is not linked against libc.so/libm.so. This could be the problem.

If you take a look at linux libstdc++.so:

0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 
0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 
0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 
0x000000000000000e (SONAME)             Library soname: [libstdc++.so.6]


While our libstc++.so (both newlib/clib2) has:

0x0000000e (SONAME)                     Library soname: [libstdc++.so]


And that's why most probably it doesn't work correctly.

i'm really tired...
Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@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?

Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@elfpipe
Quote:
so I gather the crtend.o or shcrtend.o is responsible
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.

Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@afxgroup

In case of newlib libc.so and libc.a are identical, and libm.(a|so) isn't used (the functions are in libc.(a|so) instead), there can't be a problem with that.
But the missing libgcc(_s).so may be a problem.

Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@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?

Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@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
Go to top
Re: Qt 6 progress
Just popping in
Just popping in


See User information
@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 can't stay away
Just can't stay away


See User information
@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?

Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@elfpipe

I don't know what's wrong, but I'd suggest to start testing from known working versions, i.e. GCC 2.95.x/3.4x and the corresponding binutils 2.14.x, to newer versions one by one to check which version of GCC and/or binutils exactly introduced the bugs.
That way it should be much easier to find out which changes in GCC and/or binutils cause the bugs, than just trying to find out what's wrong with the current versions which are up to 10 versions newer than the last working versions.

Go to top
Re: Qt 6 progress
Just popping in
Just popping in


See User information
@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 can't stay away
Just can't stay away


See User information
@MigthyMax

Ach, nein... Hopefully it was not because of a system update.

Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
Voila.

Quote:
11.STICK:ctor_test> test_dyn
ctor
ctor2
foo
bar
f 123
main result 123
dtor2
dtor
11.STICK:ctor_test>

Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@elfpipe
Quote:
Voila. [...]
What was the problem? An old bug in elf.library, or changes required for current versions of GCC/binutils?

Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@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.

Go to top

  Register To Post
« 1 ... 10 11 12 (13) 14 15 16 ... 20 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project