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
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
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.
- -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
__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;
}
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.
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.
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().
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
... 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.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga 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
