Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
92 user(s) are online (70 user(s) are browsing Forums)

Members: 1
Guests: 91

samo79, more...

Headlines

 
  Register To Post  

« 1 ... 12 13 14 (15) 16 17 18 ... 20 »
Re: Qt 6 progress
Amigans Defender
Amigans Defender


See User information
I'm pretty sure that -shared-libgcc/stdc++ and -static-libgcc/stdc++ are not working on our adtools. You can simply try with newlib using one of those flags with -use-dynld for example and it will be ignored. Even for these flags specs should be changed

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


See User information
@rjd324
Quote:
Implicitly, the library is linked with the c library (and gcc etc), right?
newlib: IIRC the -nostdlib disables using them, should probably be removed.

Quote:
So to do that you would still need to use -use-dynld?
No.

clib2:
- using crtbegin.o/crtend.o is wrong (I don't know what the clib2 crt0.o is), has to be changed to shcrtbegin/end.o like in the newlib version.
- -Wl,-soname,-Wl,libstdc++.so has to be changed to something like -Wl,-soname,-Wl,libstdc++_clib2.so, you can't use the same names for the incompatible newlib and clib2 libstdc++.so (in the gcc clib2 directory for building shared C++ clib2 sources it has to be stored as libstdc++.so, but in SOBJS: it has to be libstdc++_clib2.so instead).


For newlib you have to use -soname as well, at least for libstdc++.so, but maybe for libgcc.so as well.
It's extremely unlikely that current versions of the libraries are still compatible to the ancient GCC 2.95.x/3.4.x ones used for example by OWB Blastoise. I'd suggest to add the GCC version number, for example for GCC 11 use -soname libstdc++.so.11.


Edited by joerg on 2023/2/3 16:33:19
Edited by joerg on 2023/2/3 16:34:08
Edited by joerg on 2023/2/3 16:37:02
Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


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

Go to top
Re: Qt 6 progress
Home away from home
Home away from home


See User information
@elfpipe
Quote:

Quick question : Does anyone know, if the compiler tag -athread=pthread works? If yes, how to enable it? Currently it complains :


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.

I find out that there seems to be some building issue in this regard : if you find in whole adtools repo, you will find gtht-amigaos-posix.c, but not gptr-amigaos-pthreads.c , maybe there just naming typo, dunno. But we surely didn't have "posix" switch, and even if rename ghtr-amigaos-posix.c to gthr-amigaos-pthread, it still not fully implemented.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Qt 6 progress
Amigans Defender
Amigans Defender


See User information
@joerg

Quote:

- -Wl,-soname,-Wl,libstdc++.so has to be changed to something like -Wl,-soname,-Wl,libstdc++_clib2.so, you can't use the same names for the incompatible newlib and clib2 libstdc++.so (in the gcc clib2 directory for building

We don't plan to install it in SOBJS: folder. Every software compiled with new clib2 we'll have its libs in PROGDIR:Sobjs folder to be sure that nothing will cause troubles.
Otherwise you should do same stuff for any .so compiled with clib2 and it will be a great problem

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


See User information
@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.-fPIC -o lib.o
    ppc
-amigaos-gcc -shared lib.-o libs.so
    ppc
-amigaos-gcc -use-dynld -athread=single main.-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.

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


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

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


See User information
@elfpipe

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.

You need to use an extern pointer/array instead of a static one to the first entry, the one from shcrtbegin.o, of the .ctors section instead.

It's the same for static int foobar[4] __attribute__((section(".foobar")));:
Non-initialized random (or zero) data. The first entry in section .foobar is either &a or &d, I don't remember in which order GCC/ld puts them into the executable if no priorities are used.

Quote:
Which apparently means, that both the .ctors and .foobar sections are empty.
No, it only means your static __CTOR_LIST__[4] and static int foobar[4] are empty.


Edited by joerg on 2023/2/5 17:28:04
Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


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

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


See User information
@elfpipe

Quote:
This is the way the reference is made inside shcrtbegin.c. If it is wrong here, it also is there.
For the shcrtbegin.c code __attribute__((used)) may be missing, but except for that it's correct there.

For .ctors removing the
static void (*__CTOR_LIST__[4])(void) __attribute__((section(".ctors")));
should be enough since you have extern void (*__CTOR_LIST__[])(void); in function().

For the .foobar section try removing
static int foobar[4] __attribute__((section(".foobar")));
from the sources and use something like
int foobar[] = &a;
in function() instead.

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


See User information
@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"))) = { 123};

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(
flagflag--;
    }

    
// 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.

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


See User information
@elfpipe

Still the same bugs, instead of removing
extern void (*__CTOR_LIST__[])(void)
in function(), which probably was the correct way to access the .ctor function pointer array, you should have removed
static void (*__CTOR_LIST__[0])(void) __attribute__((section(".ctors")));
or now the
static void (*ctors_section[0])(void) __attribute__((section(".ctors")));
instead.

Using static can only work inside the shcrtbegin.o sources, but not in any other sources, which have to use an extern pointer/array to the (static) array in shcrtbegin.o instead.

int foobar[0] is the same, an uninitialized pointer/array.

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


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

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


See User information
@elfpipe

Quote:
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?


In case of .ctors the first entry of the array is in shcrtbegin.o and all you need is a pointer to that, i.e.
extern void (*__CTOR_LIST__[])(void);

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.

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


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

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


See User information
@elfpipe

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.

Please test removing all static variables, and to make it easier to find possible problems remove all .foobar parts for now.
Only use

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++;
if(flag) flag--;
}

return i;
}

and post the output of it.


Edit:
The above code can't work because __CTOR_LIST__[1] in shcrtbegin is, and has to be, static and can't be accessed from other sources. You'd have to build a special shcrtbegin.o only usable for this test using something like global void (*__CTOR_LIST__[1])(void) __attribute__((section(".ctors"))) = {NULL} instead.

If you only want to check if there is something wrong in the current binutils or shcrtbegin/end you can use readelf or objdump --section=.ctors libs.so:
Without constructor functions in libs.so there should only be 2 NULL pointers in section .ctors, one from shcrtbegin.o and one from shcrtend.o.
With constructor functions in libs.so the pointers to the constructor functions have to be between those 2 NULL pointers.


Edited by joerg on 2023/2/6 5:37:05
Go to top
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@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"))) = { 123};

int foobar_section[0__attribute__((section(".foobar")));


to

int foobar_section[0__attribute__((section(".foobar")));

int foobar[] __attribute__((section(".foobar"))) = { 123};



...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.

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


See User information
@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.
It was guaranteed to be at the beginning in GCC 2.95.x and 3.4.x and the bintuils 2.14.x used at the time I implemented it by the scpecs file:
shcrtbegin.o is always the first object file linked into the .so, followed by the object files and libraries used by the .so code and shcrtend.o is always the last file linked into the .so.

A possible problem might be priorities, which IIRC didn't exist in GCC 2.x/3.x yet, i.e. something like
void foo(void) __attribute__((construtor(1234))) {...}
or
class bar __attribute__((init_priority(2345)));

If that's the case the priority of the shcrtbegin NULL pointer has to be set to the smallest possible priority value and the NULL pointer in shcrtend to the largest possible priority value.

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


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

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


See User information
@elfpipe
Quote:
If, say, the startup code is modified along the lines you suggest - what would happen if a sameness of priority was to occur?
No idea what current versions of ld do in such a case, if they are using priority sorting for the complete .ctors/.dtors contents (incl. shcrtbegin/end) at all, and I din't find anything for __attribute__((constructor(priority))) but for __attribute__((init_priorty(priority))), which is basically the same, except that it's C++ only:

https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html
Quote:
... by specifying a relative priority, a constant integral expression currently bounded between 101 and 65535 inclusive. Lower numbers indicate a higher priority. ...
Which probably just means priority values below 101 and above 65535 are reserved for compiler/binutils/libc/OS parts like our shcrtbegin/end.

Go to top

  Register To Post
« 1 ... 12 13 14 (15) 16 17 18 ... 20 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project