Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
230 user(s) are online (140 user(s) are browsing Forums)

Members: 0
Guests: 230

more...

Headlines

Forum Index


Board index » All Posts (elfpipe)




Re: Qt 6 progress
Just can't stay away
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?

Go to top


Re: Qt 6 progress
Just can't stay away
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
Go to top


Re: Qt 6 progress
Just can't stay away
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.

Go to top


Re: Qt 6 progress
Just can't stay away
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.

Go to top


Re: Qt 6 progress
Just can't stay away
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.

Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


@kas1e

Quote:
Amiga bless the ones who kill the Alf !:) Is it changes was only in the file you with Max point out ? (i just about needs to commit them to adtools repo, so no one will have the same issue again)


The current solution is independent of any changes to bfd. I will have to first confer with Steven Solie. If he approves of the solution, he will do the commit and release of the new elf.library. Binutils do not need to be changed.

Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


Ok, so far so good. Qt6 is rebuildt and tested. 'connect()' calls no longer fail, and the relevant ui elements perform as they should. So I just assume, that this means 'it's working'.

Also system performance seems to be unaffected, and the few other applications I have tried seems to perform normally. So - fingers crossed - I think this is a good solution.

Now, before I start donating right and left, I would like the constructor issue to be solved as well. Overall, I think it a good measuring point to require an optimally functioning version of Qt6 before giving out gifts. So : Constructur issue. Any takers?

Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


@MigthyMax

Bingo! You nailed it. Now I have this :

Quote:
10.STICK:shlib_test> app_dyn
lib: 0x7f99d420
main: 0x7f99d420
10.STICK:shlib_test>


I will have to do some further testing. What I have done is to build elf.library to default to symbol lookup for UND symbols. I will have to confirm, that this approach works in general.

There is the caveat, that the 'world' symbol still is not set to 0, only 'hello' and 'printf'. Therefore the solution seems to be to do the default lookup.

When I have done a few more steps on the spot, I will test Qt6 to see, if the new solution improves on performance here.


Edited by elfpipe on 2023/1/7 13:51:08
Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


If an updated binutils could be produced in an official format, it would be a step in the right direction.

Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


@MigthyMax

Quote:
With the help of skateman i got access to a compiled example under linux ppc. My idea way to look how the 'symtab' and 'dynsym' entries look like.


Bingo. I was hoping, you would do that.

EDIT : What do the relocations look like on linux ppc ?

Quote:
As one can see the value is for the linux example 00000000 and not like the amiga executable 01001058. Checking the ABI a 00000000 should
trigger the dynamic linker to resolve the address of the function in the shared object file, and not the address of the PLT entry.


So this is a linker issue. You might want to look at binutils/bfd/elf32-amigaos.c to see, if you can spot where it happens.

EDIT : Which version of binutils is used on the linux ppc side ?

Quote:
So i used a HEX editor to modify the amiga executable to have even a 00000000 value for the two entries, so see if running it would result
in the expected behavior. Sadly is doesn't:


No. It has no such thing implemented. I could fix that.

Quote:
a) The gcc which writes a wrong entry into the 'symtab' and 'dyntab'
b) The dynamic linker, which just uses the value of the 'symtab' and 'dyntab' entry for UNDEF FUNC, without triggering a resoling if the value is zero.


I think, your analysis is perfect. Let's fix the beast.


Edited by elfpipe on 2023/1/4 11:59:24
Edited by elfpipe on 2023/1/4 12:11:39
Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


@MigthyMax

Quote:
So with my understanding the 'Value' value in the '.symtab' and '.dyntab' for 'world' is wrong.
Am i right?


I believe, that you are.

Quote:
In your exampled how the code should look, you use additional register 8. Did you just pick it randomly?
Because if modifying 'elf_low' and 'elf_high' and using an additional register could have unknown side
effects


Well, I fiddled a little with it. I don't know, if you can just use register 9 in place of the 8 I put, or whether it is a problem doing a la instruction from and to the same register. Just maybe to remember, that there might need to be another intermediate register. I am not an assembly wiz (any longer). Sorry!

Quote:
I checked the master github of gcc the implementation of 'elf_low' and 'elf_high' in rs6000.md. They are
still implementated like the ones in adtools. So it could be assumed, that modify them is a workaround,
and there is probably another solution, which fixes it better. We still have to find it.


I think, we not only need to modify them, but to add a replacement (pair?) that takes care of the cases of function references. Maybe there is a clue to find in gcc/gcc/config/i386 ? You can maybe perform a search for '@GOTPCREL'.

I think, you are on the right track. Keep going!


Edited by elfpipe on 2023/1/2 12:41:04
Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


@afxgroup

I think so too. I will look at it at some point, once I get my bearings. This must be solved!

Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


@Capehill

I tested the real case, replacing CONSTRUCTOR_FUNCTION tokens with __attribute__ notation. This is so bad. There are multiple shared objects, and only a selection (random?) of the constructor functions are called. This is utterly incomprehensible.

Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


@Capehill

Quote:
WTF: ctor2, foo and bar calls missing?


Exactly. That's my current scenario.

I have tested with gcc 11.3.0, and the result is the same.

This is a little bit depressing. If anyone fixes it, I will double my donation.


Edited by elfpipe on 2023/1/1 16:25:05
Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


@MigthyMax

Quote:

With my current understanding, it is just relocations which needs to be modified/removed/added
to get the correct behavior, but enlighten me if not so.


See, that's what I thought. But I am quite certain, that there needs to be implemented at least a distinction in the compiler between references to variables and references to functions ('functors' in Qt6 speech). Otherwise the linker just links function references to plt, and there is no way of making the distinction from inside elf.library.

You can take a look in the gcc source code. I am referencing 11.3.0.

Look for the folder gcc/config/rs6000. Especially in rs6000.c, rs6000-logue.c and rs6000.md there are references to functions called 'elf_high' and 'elf_low'. These are responsible for creating this assembly:

lis 9,world@ha
    la 4
,world@l(9)


If this could be changed to

lis 8,world@got@ha
la 9
,world@got@l(8)
lwz 4,0(9)


... for function references (functors), then I would be able to fix the elf.library relocator to make the references as it should be.


Edited by elfpipe on 2022/12/31 18:14:12
Edited by elfpipe on 2022/12/31 18:16:20
Edited by elfpipe on 2022/12/31 19:59:56
Edited by elfpipe on 2023/1/1 16:56:56
Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


@thread

It gets worse. Static constructors and destructors no longer work with the latest adtools. This is strange, since the exact same code + elf.library worked fine a few releases ago.

Problem:

# define Q_CONSTRUCTOR_FUNCTION0(AFUNC) \
    
namespace { \
    
static const struct AFUNC ## _ctor_class_ { \
        
inline AFUNC ## _ctor_class_() { AFUNC(); } \
    
AFUNC ## _ctor_instance_; \
    
}

# define Q_CONSTRUCTOR_FUNCTION(AFUNC) Q_CONSTRUCTOR_FUNCTION0(AFUNC)

// later on...

Q_CONSTRUCTOR_FUNCTION(qInitImageConversions);


This no longer works, and the constructor function is never called.

Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


@MigthyMax

You are right, that the reference goes to the .plt. I could confirm that in the debug version of elf.library, that I built. And that is the problem.

Inside the shared object (libhello.so) the reference goes directly to the function. Inside the main app (app_dyn) it goes to the .plt.

By looking at how this is performed on other platforms, I can assess, that on x64 the reference in the main app is linked with @gotpcrel. I think this is correct. If the main app would fetch the address from the global offset table, it would give the correct result, which would be a link to the actual function. The problem is, that this version of the truth is no realized by neither the compiler (amiga-ppc-elf32) or by elf.library. It is quite easy to make the necessary implementation in elf.library. I have already done that in several different versions. But to get the compiler to do the .got reference is another story. I am still stuck with that. Apparently there needs to be a change to both the bfd linker and the c compiler. And this is very complex code. Maybe you have some idea?

Go to top


Re: Qt 6 progress
Just can't stay away
Just can't stay away


After a bit of a rough work period, I will now give an official update on Qt6.

Due to a problem with gcc (adtools) and dynamic linking, I have not been able to release a version of Qt6 with shared objects.

The plan now is to backtrace and do a version, that uses only static linking.

The problem is described here : Issue #109 at github (adtools).

If anyone manages to flip the issue, I will donate much. Until then I have officially given up.

Go to top


Re: SpotLess debugger
Just can't stay away
Just can't stay away


@ktadd

1) This is a bug, that sneaked in during the last phase of development. I will do a fix - it is fairly easy - and do a patch release within a few days. Thanks for reporting!

2) This is the standard behavior for executables in AmigaOS. I am just using standard functions to load and run the application. In normal DOS mode, you also have to reload an app, when it has finished. There is no such thing as "keeping in memory", or "restart".

Go to top


Re: SpotLess debugger
Just can't stay away
Just can't stay away


@nbache

Quote:
Yeah, but ktadd's point is it shouldn't be saying that it was an error. It's a normal situation, so it should just be an informational message (if shown at all).


I agree with Niels. This is not an error, although the basis of making the programmatic decision is made from an error return variable from IPrefsObjects->ReadPrefs(). From the users perspective this is not an error and should probably just be given as neutral information in the Console window.

Go to top



TopTop
« 1 2 3 (4) 5 6 7 ... 74 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project