Who's Online |
43 user(s) are online ( 32 user(s) are browsing Forums)
Members: 0
Guests: 43
more...
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/19 14:39
#101
|
Just can't stay away 
|
@afxgroup
I found smartmontools on os4depot. But I don't know how to use it.
EDIT: Both my work: partition and usb drive is acting up. Perhaps virus?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/19 14:10
#102
|
Just can't stay away
|
I have a problem with my HD. I might need to buy a new one.
EDIT: Are there any good disk health programs out there?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/17 15:10
#103
|
Just can't stay away
|
@afxgroup
I have sent you a PM.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/16 17:23
#104
|
Just can't stay away
|
@afxgroup
Maybe in one hour? I need to install Discord on my laptop and a few other things first.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/16 16:50
#105
|
Just can't stay away
|
@afxgroup
Well, since constructors using .ctors now work just fine with newlib, it is definitely an issue with the specs, since (I am assuming) the compiler is the same.
Would it help you in any way, if I did the init_array implementation in elf.library real quick?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/14 13:28
#106
|
Just can't stay away
|
@afxgroup
The .init_array code still needs to be implemented in elf.library for shared objects. This is probably quite easy, but atm I'm occupied with another elf issue.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/13 10:59
#107
|
Just can't stay away
|
@thread
Thanks to all for the recommendations. I am looking forward to doing some more work on the Qt port soon.
@noXLar
It could be very easy. But as far as I remember, it uses a custom library, that needs to be ported. So it will not be enough to just use Qt6Network.
@afxgroup
If you are using latest elf.library, then be aware, that the startup code is never called. So support for init_array needs to be added to elf.library internally.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/6 16:15
#109
|
Just can't stay away
|
@joerg
I agree, that there is an issue with order when using the (section) attribute.
If, say, the startup code is modified along the lines you suggest - what would happen if a sameness of priority was to occur?
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/6 13:54
#110
|
Just can't stay away
|
@joerg Quote: Unfortunately I currently can't test anything myself, but in #291 you still have
static void (*ctors_section[0])(void) __attribute__((section(".ctors")));
which is uninitialized, random data. No, it is not. It is a valid entry in the .ctors section of size zero. BUT there is no guarantee, that it is going to be the beginning of the section. If I switch the order of foobar like this:
int foobar[] __attribute__((section(".foobar"))) = { 1, 2, 3, 0 };
int foobar_section[0] __attribute__((section(".foobar")));
to
int foobar_section[0] __attribute__((section(".foobar")));
int foobar[] __attribute__((section(".foobar"))) = { 1, 2, 3, 0 };
...then I get a valid pointer (foobar_section) to the beginning of the section. I can now read the values 1, 2, 3 (,0). 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.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/5 19:46
#111
|
Just can't stay away
|
@joerg Quote: What you are doing instead is using a local (static) __CTOR_LIST__[], which is empty. The GCC code generator prefers using local (static) data/pointers over external ones and you always get the wrong pointer as long as you have a local (with or without "static") variable with the same name. Which is of course not what I wanted (although it still worked). I have changed the name of the variable in #291. Now it should be clear what I want to do.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/5 18:52
#112
|
Just can't stay away
|
@joerg
But I want to access the section data? How can I do this, if I don't have a variable, that is initialized to point to the section?
Look at the code again, I updated the example slightly. NOTE: It functions correctly with the ctors_section variable now. It contains two pointers, foo and bar.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/5 18:42
#113
|
Just can't stay away
|
@joerg I am beginning to see the picture. This is the current test :
#include "lib.h"
void foo(void) __attribute__((constructor));
void bar(void) __attribute__((constructor));
static void (*ctors_section[0])(void) __attribute__((section(".ctors")));
void foo() {
printf("foo\n");
}
void bar() {
printf("bar\n");
}
int foobar[] __attribute__((section(".foobar"))) = { 1, 2, 3, 0 };
int foobar_section[0] __attribute__((section(".foobar")));
int function(int f)
{
// extern void (*__CTOR_LIST__[])(void);
int i = 0;
int flag = 0;
while (ctors_section[i] || flag)
{
printf("Constructor function : 0x%x\n", (void*)ctors_section[i]);
i++;
if(flag) flag--;
}
// extern int foobar[];
int j = 0;
while (foobar_section[j])
{
printf("foobar : %d\n", foobar_section[j]);
j++;
}
return f;
}
So apparently giving a size to the variable with the __attribute((section(".somesection")) adds space to the section. I was looking for a way to reference the section (I could have called it anything appart from __CTOR_LIST__) without adding elements. This seems to be possible with the array [], setting it to [0]. If I give it a value of [4] in the current test, the flag variable will enable me to read the full section, if I set flag=4. In the current test, if I reference the foobar_section variable, then of course I get the right result. BUT the test above, where I try and access the section from another variable fails. It will just give random numbers. This seems to indicate, that the section is not properly loaded/initialized. To further comment on the .ctors variable : If I run with elf.library v 53.27, it will now crash in the startup code, because the section is not relocated, and the startup code will try and execute a function pointer, that is unrelocated. So I think it is safe to say, that currently the sections referenced by __attribute((section)) in the code are not, by default, initialized with the proper data. Currently, with elf.library 53.37, the .ctors section variable gives the right result, but that is only due to the fact, that a relocator is called explicitly on the .ctors section from within the elf.library startup code. A generic loading of sections is simply missing.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/5 17:36
#114
|
Just can't stay away
|
@joerg Quote: I don't have access to the newlib sources any more, but there is a problem with your code:
static void (*__CTOR_LIST__[4])(void) __attribute__((section(".ctors"))); isn't initialized anywhere, and I don't understand what it's supposed to be used for. This is the way the reference is made inside shcrtbegin.c. If it is wrong here, it also is there. Q: If I remove it, how will I access the elements in .ctors? I have to make a reference somehow to be able to loop in function().
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/5 15:45
#115
|
Just can't stay away
|
@kas1e Quote: I asked Sebastian about the same year ago when meet with this error , and he says it wasn't implemented, but it should be "easy", like a matter to wrote gthr file for. If this could be produced, it would save me a lot of headache.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/5 15:23
#116
|
Just can't stay away
|
@joerg Quote: To check if it still works use something like
__attribute__((section("foobar"))) int foobar = 1; I am not sure if I am doing things correctly here, so please elaborate, if there is something, that should be handled differently. My test so far looks like this :
//lib.h
#include <stdio.h>
extern int function(int f);
//lib.c
#include "lib.h"
void foo(void) __attribute__((constructor));
void bar(void) __attribute__((constructor));
void foo() {
printf("foo\n");
}
void bar() {
printf("bar\n");
}
static void (*__CTOR_LIST__[4])(void) __attribute__((section(".ctors")));
__attribute__((section(".foobar"))) int a = 1;
__attribute__((section(".foobar"))) int b = 2;
__attribute__((section(".foobar"))) int c = 3;
__attribute__((section(".foobar"))) int d = 0;
static int foobar[4] __attribute__((section(".foobar")));
int function(int f)
{
extern void (*__CTOR_LIST__[])(void);
int i = 0;
int flag = 1;
while (__CTOR_LIST__[i] || flag)
{
printf("Constructor function : 0x%x\n", (void*)__CTOR_LIST__[i]);
i++;
flag = 0;
}
extern int foobar[];
int j = 0;
int flag2 = 1;
while (foobar[i] || flag2)
{
printf("foobar : %d\n", foobar[j]);
j++;
flag2 = 0;
}
return f;
}
//main.c
#include "lib.h"
int main()
{
printf("result: %d\n", function(123));
return 0;
}
//Makefile
all:
ppc-amigaos-gcc -c lib.c -fPIC -o lib.o
ppc-amigaos-gcc -shared lib.o -o libs.so
ppc-amigaos-gcc -use-dynld -athread=single main.c -L. -ls -o test
Depending on the version of elf.library, that you are using, you are going to get something like this: Quote: 11.STICK:section_test> test
bar
foo
Constructor function : 0x0
foobar : 0
result: 123
11.STICK:section_test> Which apparently means, that both the .ctors and .foobar sections are empty.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/2 18:01
#117
|
Just can't stay away
|
Quick question : Does anyone know, if the compiler tag -athread=pthread works? If yes, how to enable it? Currently it complains : Quote: /opt/adtools/lib/gcc/ppc-amigaos/9.1.0/../../../../ppc-amigaos/bin/ld: cannot find gthr-amigaos-pthread.o: No such file or directory
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/1 13:18
#118
|
Just can't stay away
|
@afxgroup Quote: And the main problem is that _init function is called inside the program and instead of loading that one in libc.so it is calling that one present (and is wrong) in the exe file. So the constructors are not called and (for example) libstdc++.so crash because files are not opened. Please make sure, that you update elf.library before testing this. In the new version, the correct constructors should be called from the entries in the .ctors section, and there should be no need to double it. I'm not sure, if calling a constructor twice could be a problem (Qt does this), but better to make sure. The latest version of elf.library is 53.37. Are you planning on a new release of adtools? If you get there, please let me know.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/2/1 11:14
#119
|
Just can't stay away
|
@MigthyMax Quote: Just out of curiosity, TLS (ThreadLocalStorage) isn't required/needed by QT 6? Qt has some form of tls, but I don't know enough on the subject to give you the details. EDIT : Qt6 has some problem with threading at the moment. Apparently thread.wait() is called on the main thread, which is not good. I have troubles understanding, how this could be connected to dynamic vs. static linking. It works on static.
|
|
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/30 16:46
#120
|
Just can't stay away
|
@MigthyMax Quote: That's great progress. Nothing is stopping you to continue with QT6, or? Well... There seems to be more issues with dynamic linking. Some ui functions are off, and they used to work, even with dynamic link. So I am off to try a different compiler version (most likely gcc 11) and reconfigure my Qt6 setup. One thing : I have a suspicion, that something is off with the Quote: tag in gcc. If someone can come up with a test and/or solution, it will be rewarded.
|
|
|
|
|
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
