Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
100 user(s) are online (58 user(s) are browsing Forums)

Members: 0
Guests: 100

more...

Headlines

 
  Register To Post  

« 1 ... 7 8 9 (10) 11 12 13 ... 20 »
Re: Qt 6 progress
Just can't stay away
Just can't stay away


See User information
@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 popping in
Just popping in


See User information
@elfpipe

I see you, have been much deeper down the rabbit hole than I. But i will try to follow you.

Starting with the C example at adtools@issue109, and focusing on the dynamic compilation part,
e.g app_dyn and libhello.so. Could you tell me what needs to be modified in which file?

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.

BTW i couldn't find any source about where the PPC relocation are defined, do you have source at hand?

And I found this article, which even mention that the address of an function is not always the same. Maybe gives some more insight.

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


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


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


See User information
@elfpipe

Quote:

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.


Do you mean in context of shared objects? I have had some headaches with library constructor calls.

I tested your example and it seems to work as long as I don't declare any __attribute__((constructor)) stuff. If I do, then only one constructor is called. I don't understand the issue at all :(

My examples:

// library code
#include <proto/exec.h>
#include <stdio.h>

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

#define CONSTRUCTOR_FUNCTION(AFUNC) CONSTRUCTOR_FUNCTION0(AFUNC)

void foo()
{
    
printf("%s\n"__func__);
}

void bar()
{
    
printf("%s\n"__func__);
}

CONSTRUCTOR_FUNCTION(foo);
CONSTRUCTOR_FUNCTION(bar);

#if 1
void __attribute__((constructor(1000))) ctor()
{
    
printf("%s\n"__func__);
}

void  __attribute__((destructor(1000))) dtor()
{
    
printf("%s\n"__func__);
}

void __attribute__((constructor(2000))) ctor2()
{
    
printf("%s\n"__func__);
}

void  __attribute__((destructor(2000))) dtor2()
{
    
printf("%s\n"__func__);
}
#endif

int f(int x)
{
    
printf("%s %d\n"__func__x);

    return 
x;
}

// main

#include <stdio.h>

int f(int);

int main()
{
    
int result f(123);

    
printf("%s result %d\n"__func__result);

    return 
0;
}

// makefile

CC=g++

all:
    $(
CC) -o lib.-c lib.-fPIC
    
$(CC) -o libf.so lib.-shared
    ar cruv  libf
.a lib.o
    ranlib libf
.
    
$(CC) -o test_dyn main.-use-dynld -L. -lf -athread=native 
    
$(CC) -o test_static main.-L. -lf -athread=native


Results (GCC 11.2):

Quote:

constructor> test_static
ctor
ctor2
foo
bar
f 123
main result 123
dtor2
dtor

So far so good.

constructor> test_dyn
ctor
f 123
main result 123
dtor2
dtor

WTF: ctor2, foo and bar calls missing?

Then I disable __attribute__ stuff and things get more consistent:

constructor> test_dyn
foo
bar
f 123
main result 123

constructor> test_static
foo
bar
f 123
main result 123


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


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


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


See User information
I don't know if it can be related. But I have a problem with constructors in clib2 when using shared objects and libstdc++.so.
Basically c++ constructors (for examples streams constructors) are called too early. Before libc constructors and so I have a crash because libc is not initialized yet. I've tried several workarounds but with no luck. I suspect there is something in elf.library that is causing this but I don't understand what

i'm really tired...
Go to top
Re: Qt 6 progress
Just popping in
Just popping in


See User information
@elfpipe

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


If you look at the ABI specification (hopefully the correct ABI for AmigaOS 4), you see in
chapter 4.3.3, that the use case to use the address of an function is considered. Sadly this is a very short chapter,
but the to get it working there must be a symbol table entry. The interesting part is if that entry is present in the
app_dyn? So lets see if i find it:

[0]>Work:Home/Workspaces/109>readelf -s app_dyn

Symbol table 
'.dynsym' contains 13 entries:
   
Num:    Value  Size Type    Bind   Vis      Ndx Name
     0
00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1
010100d8     4 OBJECT  GLOBAL DEFAULT   16 __stdiowin
     2
: 01001048     8 FUNC    GLOBAL DEFAULT  UND printf
     3
01001050    84 FUNC    GLOBAL DEFAULT  UND hello
     4
010100c8     0 NOTYPE  GLOBAL DEFAULT   15 _DATA_BASE_
     5
: 01001058    28 FUNC    GLOBAL DEFAULT  UND world
     6
010100dc     4 OBJECT  GLOBAL DEFAULT   16 __unix_path_semantics
     7
: 010180d8     0 NOTYPE  GLOBAL DEFAULT   16 _SDA_BASE_
     8
010100e0     4 OBJECT  GLOBAL DEFAULT   16 INewlib
     9
010100d8     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
    10
00000001     0 NOTYPE  GLOBAL DEFAULT  ABS __amigaos4__
    11
010100d8     0 NOTYPE  GLOBAL DEFAULT  ABS _edata
    12
01010100     0 NOTYPE  GLOBAL DEFAULT  ABS _end

Symbol table 
'.symtab' contains 41 entries:
   
Num:    Value  Size Type    Bind   Vis      Ndx Name
     0
00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1
010000f4     0 SECTION LOCAL  DEFAULT    
     2
: 01000108     0 SECTION LOCAL  DEFAULT    
     3
01000150     0 SECTION LOCAL  DEFAULT    
     4
01000220     0 SECTION LOCAL  DEFAULT    
     5
010002b8     0 SECTION LOCAL  DEFAULT    
     6
010002d0     0 SECTION LOCAL  DEFAULT    
     7
010002f4     0 SECTION LOCAL  DEFAULT    
     8
01001000     0 SECTION LOCAL  DEFAULT    
     9
01002000     0 SECTION LOCAL  DEFAULT   10 
    10
01002040     0 SECTION LOCAL  DEFAULT   11 
    11
01010000     0 SECTION LOCAL  DEFAULT   12 
    12
: 01010008     0 SECTION LOCAL  DEFAULT   13 
    13
01010010     0 SECTION LOCAL  DEFAULT   14 
    14
010100c8     0 SECTION LOCAL  DEFAULT   15 
    15
010100d8     0 SECTION LOCAL  DEFAULT   16 
    16
00000000     0 SECTION LOCAL  DEFAULT   17 
    17
00000000     0 FILE    LOCAL  DEFAULT  ABS main.c
    18
01010010     0 OBJECT  LOCAL  HIDDEN   14 _DYNAMIC
    19
010100cc     0 OBJECT  LOCAL  HIDDEN   15 _GLOBAL_OFFSET_TABLE_
    20
010100d8     4 OBJECT  GLOBAL DEFAULT   16 __stdiowin
    21
: 01001048     8 FUNC    GLOBAL DEFAULT  UND printf
    22
010100f4     4 OBJECT  GLOBAL DEFAULT   16 UtilityBase
    23
01001050    84 FUNC    GLOBAL DEFAULT  UND hello
    24
010100c8     0 NOTYPE  GLOBAL DEFAULT   15 _DATA_BASE_
    25
010100e8     4 OBJECT  GLOBAL DEFAULT   16 IExec
    26
: 01001058    28 FUNC    GLOBAL DEFAULT  UND world
    27
010100f8     4 OBJECT  GLOBAL DEFAULT   16 IUtility
    28
010100dc     4 OBJECT  GLOBAL DEFAULT   16 __unix_path_semantics
    29
010100f0     4 OBJECT  GLOBAL DEFAULT   16 __reent_magic
    30
010100ec     4 OBJECT  GLOBAL DEFAULT   16 DOSBase
    31
010002f4  1100 FUNC    GLOBAL DEFAULT    7 _start
    32
: 010180d8     0 NOTYPE  GLOBAL DEFAULT   16 _SDA_BASE_
    33
010100e0     4 OBJECT  GLOBAL DEFAULT   16 INewlib
    34
010100d8     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
    35
01000740    80 FUNC    GLOBAL DEFAULT    7 main
    36
00000001     0 NOTYPE  GLOBAL DEFAULT  ABS __amigaos4__
    37
010100d8     0 NOTYPE  GLOBAL DEFAULT  ABS _edata
    38
01010100     0 NOTYPE  GLOBAL DEFAULT  ABS _end
    39
010100f0     4 OBJECT  GLOBAL DEFAULT   16 SysBase
    40
010100e4     4 OBJECT  GLOBAL DEFAULT   16 IDOS


As is see it, there is an entry for the world both in '.dynsym' and '.symtab' section. Interpreting
chapter 4.3.3 from the ABI, the dynamic linker should behave like this:

Quote:
If the st_shndx member is SHN_UNDEF and the symbol is of type STT_FUNC and the st_value member
is not zero, the dynamic linker recognizes this entry as special and uses the st_value member as the
symbol’s address.


Thus the value 01001058 should be used as the symbol address. But looking at the '.rela.plt‘ section
of the app_dyn:

[0]>Work:Home/Workspaces/109>readelf -r app_dyn

Relocation section 
'.rela.sbss' at offset 0x2b8 contains 2 entries:
 
Offset     Info    Type            Sym.Value  SymName Addend
010100d8  00000113 R_PPC_COPY        010100d8   __stdiowin 
0
010100dc  00000613 R_PPC_COPY        010100dc   __unix_path_semantics 
0

Relocation section 
'.rela.plt' at offset 0x2d0 contains 3 entries:
 
Offset     Info    Type            Sym.Value  SymName Addend
01001048  00000215 R_PPC_JMP_SLOT    01001048   printf 0
01001050  00000315 R_PPC_JMP_SLOT    01001050   hello 
0
01001058  00000515 R_PPC_JMP_SLOT    01001058   world 0

Relocation section 
'.rela.text' at offset 0x104e4 contains 60 entries:
 
Offset     Info    Type            Sym.Value  SymName Addend
010002fe  00002006 R_PPC_ADDR16_HA   
010180d8   _SDA_BASE_ 0
01000302  00002706 R_PPC_ADDR16_HA   010100f0   SysBase 
0
01000306  00002704 R_PPC_ADDR16_LO   010100f0   SysBase 
0
0100031a  00002004 R_PPC_ADDR16_LO   
010180d8   _SDA_BASE_ 0
0100034e  
00001906 R_PPC_ADDR16_HA   010100e8   IExec 0
01000352  
00000906 R_PPC_ADDR16_HA   01002000   .rodata 0
01000356  
00001904 R_PPC_ADDR16_LO   010100e8   IExec 0
0100035e  
00000904 R_PPC_ADDR16_LO   01002000   .rodata 0
0100037a  
00000906 R_PPC_ADDR16_HA   01002000   .rodata 10
01000382  00000904 R_PPC_ADDR16_LO   01002000   .rodata 10
010003ae  00001606 R_PPC_ADDR16_HA   010100f4   UtilityBase 
0
010003b2  
00000906 R_PPC_ADDR16_HA   01002000   .rodata 18
010003ba  00001b06 R_PPC_ADDR16_HA   010100f8   IUtility 
0
010003c2  00001604 R_PPC_ADDR16_LO   010100f4   UtilityBase 
0
010003c6  
00000904 R_PPC_ADDR16_LO   01002000   .rodata 18
010003d2  00001b04 R_PPC_ADDR16_LO   010100f8   IUtility 
0
0100040e  00001c06 R_PPC_ADDR16_HA   010100dc   __unix_path_semantics 
0
01000416  00000a06 R_PPC_ADDR16_HA   01002040   
.__newlib_version 0
0100041a  00001c04 R_PPC_ADDR16_LO   010100dc   __unix_path_semantics 
0
01000422  00000a04 R_PPC_ADDR16_LO   01002040   
.__newlib_version 0
01000456  00002106 R_PPC_ADDR16_HA   010100e0   INewlib 
0
0100045a  00002104 R_PPC_ADDR16_LO   010100e0   INewlib 
0
0100047e  00000c06 R_PPC_ADDR16_HA   
01010008   .dtors 0
01000482  00000b06 R_PPC_ADDR16_HA   01010000   .ctors 0
01000486  00000c04 R_PPC_ADDR16_LO   01010008   .dtors 0
0100048a  00000b04 R_PPC_ADDR16_LO   01010000   .ctors 0
01000496  00001406 R_PPC_ADDR16_HA   010100d8   __stdiowin 0
0100049e  00002306 R_PPC_ADDR16_HA   01000740   main 0
010004a2  
00002806 R_PPC_ADDR16_HA   010100e4   IDOS 0
010004aa  00001e06 R_PPC_ADDR16_HA   010100ec   DOSBase 
0
010004b2  00001404 R_PPC_ADDR16_LO   010100d8   __stdiowin 
0
010004be  00002304 R_PPC_ADDR16_LO   01000740   main 
0
010004c2  
00002804 R_PPC_ADDR16_LO   010100e4   IDOS 0
010004ca  00001e04 R_PPC_ADDR16_LO   010100ec   DOSBase 
0
01000506  00001b04 R_PPC_ADDR16_LO   010100f8   IUtility 
0
010005be  00001b04 R_PPC_ADDR16_LO   010100f8   IUtility 
0
010005da  
00000906 R_PPC_ADDR16_HA   01002000   .rodata 28
010005e2  
00000904 R_PPC_ADDR16_LO   01002000   .rodata 28
0100062a  00000c06 R_PPC_ADDR16_HA   
01010008   .dtors 0
0100062e  00000b06 R_PPC_ADDR16_HA   01010000   
.ctors 0
01000636  00000c04 R_PPC_ADDR16_LO   
01010008   .dtors 0
0100063a  00000b04 R_PPC_ADDR16_LO   01010000   
.ctors 0
01000646  00001e06 R_PPC_ADDR16_HA   010100ec   DOSBase 
0
0100064e  
00002806 R_PPC_ADDR16_HA   010100e4   IDOS 0
01000652  00001406 R_PPC_ADDR16_HA   010100d8   __stdiowin 
0
0100065a  00002306 R_PPC_ADDR16_HA   01000740   main 
0
01000666  00001e04 R_PPC_ADDR16_LO   010100ec   DOSBase 
0
0100066a  00002304 R_PPC_ADDR16_LO   01000740   main 
0
0100066e  
00002804 R_PPC_ADDR16_LO   010100e4   IDOS 0
01000682  00001404 R_PPC_ADDR16_LO   010100d8   __stdiowin 0
010006c2  00001b06 R_PPC_ADDR16_HA   010100f8   IUtility 
0
010006c6  00001b04 R_PPC_ADDR16_LO   010100f8   IUtility 
0
010006fe  00001b06 R_PPC_ADDR16_HA   010100f8   IUtility 
0
01000702  00001b04 R_PPC_ADDR16_LO   010100f8   IUtility 
0
01000754  0000170a R_PPC_REL24       01001050   hello 
0
0100075a  
00000906 R_PPC_ADDR16_HA   01002000   .rodata 34
0100075e  
00000904 R_PPC_ADDR16_LO   01002000   .rodata 34
01000762  00001a06 R_PPC_ADDR16_HA   
01001058   world 0
01000766  00001a04 R_PPC_ADDR16_LO   
01001058   world 0
0100076c  0000150a R_PPC_REL24       
01001048   printf 0


that 01001058 is the address of the PLT entry.

So with my understanding the 'Value' value in the '.symtab' and '.dyntab' for 'world' is wrong.
Am i right? And the cause for being wrong is, like you even think, that the toolchain doesn't
differ if the function is called or the address used. (I probably need to compile the example
under PPC 32 BE Linux and see how section look there)


I looked into the folder gcc/config/rs6000 and peeked into rs6000.c, rs6000-logue.c and rs6000.md
(ignored all others). That's heavy stuff. I see why modifying 'elf_low' and 'elf_high' could solve
the issue. But how to modify them is a guessing. But i have some doubt/questions about going for that way:

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.

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.

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


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


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


See User information
@elfpipe

Quote:


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.



I opened a new ticket for tracking purposes.

https://github.com/sba1/adtools/issues/139

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


See User information
@elfpipe

I think the address issue is worse than thought. I now think it is a bug distributed in the adtools gcc and the dynamic linker (elf.library??). Let me explain why, i think so.

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.

readelf -s app_dyn_linux grep world
      4
00000000     0 FUNC    GLOBAL DEFAULT  UND world
     67
00000000     0 FUNC    GLOBAL DEFAULT  UND world


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

[0]:Work;Home/Workspaces/109>app_dyn_modified
lib
0x7f9ac408
main
0x0


Seeing that result i think there a two bugs:

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.

Point a could possible be fixed if digging into the gcc source, but for point b someone with access to the dynmaic linker implementation would be helpful.

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


See User information
@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 popping in
Just popping in


See User information
@elfpipe

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


Here a complete dump of the app_dyn_linx

ELF Header:   Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
   
Class:                             ELF32
   Data
:                              2's complement, big endian
   Version:                           1 (current)
   OS/ABI:                            UNIX - System V
   ABI Version:                       0
   Type:                              DYN (Position-Independent Executable file)
   Machine:                           PowerPC
   Version:                           0x1
   Entry point address:               0x500
   Start of program headers:          52 (bytes into file)
   Start of section headers:          71940 (bytes into file)
   Flags:                             0x0
   Size of this header:               52 (bytes)
   Size of program headers:           32 (bytes)
   Number of program headers:         9
   Size of section headers:           40 (bytes)
   Number of section headers:         35
   Section header string table index: 34

Section Headers:
   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
   [ 1] .interp           PROGBITS        00000154 000154 00000d 00   A  0   0  1
   [ 2] .note.gnu.bu[...] NOTE            00000164 000164 000024 00   A  0   0  4
   [ 3] .note.ABI-tag     NOTE            00000188 000188 000020 00   A  0   0  4
   [ 4] .gnu.hash         GNU_HASH        000001a8 0001a8 000020 04   A  5   0  4
   [ 5] .dynsym           DYNSYM          000001c8 0001c8 0000b0 10   A  6   2  4
   [ 6] .dynstr           STRTAB          00000278 000278 0000bf 00   A  0   0  1
   [ 7] .gnu.version      VERSYM          00000338 000338 000016 02   A  5   0  2
   [ 8] .gnu.version_r    VERNEED         00000350 000350 000040 00   A  6   1  4
   [ 9] .rela.dyn         RELA            00000390 000390 0000e4 0c   A  5   0  4
   [10] .rela.plt         RELA            00000474 000474 00003c 0c  AI  5  22  4
   [11] .init             PROGBITS        000004b0 0004b0 000044 00  AX  0   0  4
   [12] .text             PROGBITS        00000500 000500 000370 00  AX  0   0 16
   [13] .fini             PROGBITS        00000870 000870 00002c 00  AX  0   0  4
   [14] .rodata           PROGBITS        0000089c 00089c 00000e 00   A  0   0  4
   [15] .eh_frame_hdr     PROGBITS        000008ac 0008ac 00002c 00   A  0   0  4
   [16] .eh_frame         PROGBITS        000008d8 0008d8 0000b0 00   A  0   0  4
   [17] .init_array       INIT_ARRAY      0001febc 00febc 000004 04  WA  0   0  4
   [18] .fini_array       FINI_ARRAY      0001fec0 00fec0 000004 04  WA  0   0  4
   [19] .got2             PROGBITS        0001fec4 00fec4 00002c 00  WA  0   0  4
   [20] .dynamic          DYNAMIC         0001fef0 00fef0 000100 08  WA  6   0  4
   [21] .got              PROGBITS        0001fff0 00fff0 000010 04  WA  0   0  4
   [22] .plt              PROGBITS        00020000 010000 000014 00  WA  0   0  4
   [23] .data             PROGBITS        00020014 010014 000018 00  WA  0   0  4
   [24] .bss              NOBITS          0002002c 01002c 000004 00  WA  0   0  1
   [25] .comment          PROGBITS        00000000 01002c 00001b 01  MS  0   0  1
   [26] .debug_aranges    PROGBITS        00000000 010048 0000a0 00      0   0  8
   [27] .debug_info       PROGBITS        00000000 0100e8 000573 00      0   0  1
   [28] .debug_abbrev     PROGBITS        00000000 01065b 00018f 00      0   0  1
   [29] .debug_line       PROGBITS        00000000 0107ea 000253 00      0   0  1
   [30] .debug_str        PROGBITS        00000000 010a3d 0004ed 01  MS  0   0  1
   [31] .debug_ranges     PROGBITS        00000000 010f30 000040 00      0   0  8
   [32] .symtab           SYMTAB          00000000 010f70 000550 10     33  63  4
   [33] .strtab           STRTAB          00000000 0114c0 0002f4 00      0   0  1
   [34] .shstrtab         STRTAB          00000000 0117b4 00014e 00      0   0  1
Key to Flags:
   W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
   L (link order), O (extra OS processing required), G (group), T (TLS),
   C (compressed), x (unknown), o (OS specific), E (exclude),
   D (mbind), v (VLE), p (processor specific)

There are no section groups in this file.

Program Headers:
   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
   PHDR           0x000034 0x00000034 0x00000034 0x00120 0x00120 R   0x4
   INTERP         0x000154 0x00000154 0x00000154 0x0000d 0x0000d R   0x1
       [Requesting program interpreter: /lib/ld.so.1]
   LOAD           0x000000 0x00000000 0x00000000 0x00988 0x00988 R E 0x10000
   LOAD           0x00febc 0x0001febc 0x0001febc 0x00170 0x00174 RW  0x10000
   DYNAMIC        0x00fef0 0x0001fef0 0x0001fef0 0x00100 0x00100 RW  0x4
   NOTE           0x000164 0x00000164 0x00000164 0x00044 0x00044 R   0x4
   GNU_EH_FRAME   0x0008ac 0x000008ac 0x000008ac 0x0002c 0x0002c R   0x4
   GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
   GNU_RELRO      0x00febc 0x0001febc 0x0001febc 0x00144 0x00144 R   0x1

Section to Segment mapping:
   Segment Sections...
    00
    01     .interp 
    02     .interp .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .text .fini .rodata .eh_frame_hdr .eh_frame  
    03     .init_array .fini_array .got2 .dynamic .got .plt .data .bss 
    04     .dynamic 
    05     .note.gnu.build-id .note.ABI-tag 
    06     .eh_frame_hdr 
    07 
    08     .init_array .fini_array .got2 .dynamic .got

Dynamic section at offset 0xfef0 contains 28 entries:
   Tag        Type                         Name/Value
  0x00000001 (NEEDED)                     Shared library: [libhello.so]
  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
  0x0000000c (INIT)                       0x4b0
  0x0000000d (FINI)                       0x870
  0x00000019 (INIT_ARRAY)                 0x1febc
  0x0000001b (INIT_ARRAYSZ)               4 (bytes)
  0x0000001a (FINI_ARRAY)                 0x1fec0
  0x0000001c (FINI_ARRAYSZ)               4 (bytes)
  0x6ffffef5 (GNU_HASH)                   0x1a8
  0x00000005 (STRTAB)                     0x278
  0x00000006 (SYMTAB)                     0x1c8
  0x0000000a (STRSZ)                      191 (bytes)
  0x0000000b (SYMENT)                     16 (bytes)
  0x00000015 (DEBUG)                      0x0
  0x00000003 (PLTGOT)                     0x20000
  0x00000002 (PLTRELSZ)                   60 (bytes)
  0x00000014 (PLTREL)                     RELA
  0x00000017 (JMPREL)                     0x474
  0x00000007 (RELA)                       0x390
  0x00000008 (RELASZ)                     288 (bytes)
  0x00000009 (RELAENT)                    12 (bytes)
  0x70000000 (PPC_GOT)                    0x1fff4
  0x6ffffffb (FLAGS_1)                    Flags: PIE
  0x6ffffffe (VERNEED)                    0x350 
  0x6fffffff (VERNEEDNUM)                 1
  0x6ffffff0 (VERSYM)                     0x338
  0x6ffffff9 (RELACOUNT)                  14
  0x00000000 (NULL)                       0x0

Relocation section '
.rela.dyn' at offset 0x390 contains 19 entries:
  Offset     Info    Type            Sym.Value  Sym. Name + Addend
0001febc  00000016 R_PPC_RELATIVE               660
0001fec0  00000016 R_PPC_RELATIVE               5f0
0001fec4  00000016 R_PPC_RELATIVE               2002c
0001fecc  00000016 R_PPC_RELATIVE               2002c
0001fed4  00000016 R_PPC_RELATIVE               2002c
0001fedc  00000016 R_PPC_RELATIVE               20028
0001fee4  00000016 R_PPC_RELATIVE               8a0
0001fee8  00000016 R_PPC_RELATIVE               1fec0
0001feec  00000016 R_PPC_RELATIVE               1febc
00020014  00000016 R_PPC_RELATIVE               1fff4
00020018  00000016 R_PPC_RELATIVE               664
0002001c  00000016 R_PPC_RELATIVE               6c4
00020020  00000016 R_PPC_RELATIVE               7c4
00020028  00000016 R_PPC_RELATIVE               20028
0001fec8  00000201 R_PPC_ADDR32      00000000   _ITM_deregisterTM[...] + 0
0001fed0  00000901 R_PPC_ADDR32      00000000   _ITM_registerTMCl[...] + 0
0001fed8  00000501 R_PPC_ADDR32      00000000   __cxa_finalize@GLIBC_2.1.3 + 0
0001fee0  00000401 R_PPC_ADDR32      00000000   world + 0
0001fff0  00000714 R_PPC_GLOB_DAT    00000000   __gmon_start__ + 0

Relocation section '
.rela.plt' at offset 0x474 contains 5 entries:
  Offset     Info    Type            Sym.Value  Sym. Name + Addend
00020000  00000315 R_PPC_JMP_SLOT    00000000   printf@GLIBC_2.4 + 0
00020004  00000515 R_PPC_JMP_SLOT    00000000   __cxa_finalize@GLIBC_2.1.3 + 0
00020008  00000615 R_PPC_JMP_SLOT    00000000   hello + 0 
0002000c  00000715 R_PPC_JMP_SLOT    00000000   __gmon_start__ + 0 
00020010  00000815 R_PPC_JMP_SLOT    00000000   __libc_start_main@GLIBC_2.0 + 0

The decoding of unwind sections for machine type PowerPC is not currently supported.

Symbol table '
.dynsym' contains 11 entries:
    Num:    Value  Size Type    Bind   Vis      Ndx Name
      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
      1: 000004b0     0 SECTION LOCAL  DEFAULT   11 .init
      2: 00000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterT[...]
      3: 00000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.4 (2)
      4: 00000000     0 FUNC    GLOBAL DEFAULT  UND world
      5: 00000000     0 FUNC    WEAK   DEFAULT  UND [...]@GLIBC_2.1.3 (3)
      6: 00000000     0 FUNC    GLOBAL DEFAULT  UND hello
      7: 00000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
      8: 00000000     0 FUNC    GLOBAL DEFAULT  UND __[...]@GLIBC_2.0 (4)
      9: 00000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMC[...]
     10: 0000089c     4 OBJECT  GLOBAL DEFAULT   14 _IO_stdin_used

Symbol table '
.symtab' contains 85 entries:
    Num:    Value  Size Type    Bind   Vis      Ndx Name 
      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
      1: 00000154     0 SECTION LOCAL  DEFAULT    1 .interp
      2: 00000164     0 SECTION LOCAL  DEFAULT    2 .note.gnu.build-id
      3: 00000188     0 SECTION LOCAL  DEFAULT    3 .note.ABI-tag
      4: 000001a8     0 SECTION LOCAL  DEFAULT    4 .gnu.hash
      5: 000001c8     0 SECTION LOCAL  DEFAULT    5 .dynsym
      6: 00000278     0 SECTION LOCAL  DEFAULT    6 .dynstr
      7: 00000338     0 SECTION LOCAL  DEFAULT    7 .gnu.version
      8: 00000350     0 SECTION LOCAL  DEFAULT    8 .gnu.version_r
      9: 00000390     0 SECTION LOCAL  DEFAULT    9 .rela.dyn
     10: 00000474     0 SECTION LOCAL  DEFAULT   10 .rela.plt
     11: 000004b0     0 SECTION LOCAL  DEFAULT   11 .init
     12: 00000500     0 SECTION LOCAL  DEFAULT   12 .text
     13: 00000870     0 SECTION LOCAL  DEFAULT   13 .fini
     14: 0000089c     0 SECTION LOCAL  DEFAULT   14 .rodata
     15: 000008ac     0 SECTION LOCAL  DEFAULT   15 .eh_frame_hdr
     16: 000008d8     0 SECTION LOCAL  DEFAULT   16 .eh_frame
     17: 0001febc     0 SECTION LOCAL  DEFAULT   17 .init_array
     18: 0001fec0     0 SECTION LOCAL  DEFAULT   18 .fini_array
     19: 0001fec4     0 SECTION LOCAL  DEFAULT   19 .got2
     20: 0001fef0     0 SECTION LOCAL  DEFAULT   20 .dynamic
     21: 0001fff0     0 SECTION LOCAL  DEFAULT   21 .got
     22: 00020000     0 SECTION LOCAL  DEFAULT   22 .plt
     23: 00020014     0 SECTION LOCAL  DEFAULT   23 .data
     24: 0002002c     0 SECTION LOCAL  DEFAULT   24 .bss
     25: 00000000     0 SECTION LOCAL  DEFAULT   25 .comment
     26: 00000000     0 SECTION LOCAL  DEFAULT   26 .debug_aranges
     27: 00000000     0 SECTION LOCAL  DEFAULT   27 .debug_info
     28: 00000000     0 SECTION LOCAL  DEFAULT   28 .debug_abbrev
     29: 00000000     0 SECTION LOCAL  DEFAULT   29 .debug_line
     30: 00000000     0 SECTION LOCAL  DEFAULT   30 .debug_str
     31: 00000000     0 SECTION LOCAL  DEFAULT   31 .debug_ranges
     32: 00000000     0 FILE    LOCAL  DEFAULT  ABS abi-note.c
     33: 00000188    32 OBJECT  LOCAL  DEFAULT    3 __abi_tag
     34: 00000000     0 FILE    LOCAL  DEFAULT  ABS /builddir/glibc-[...]
     35: 0000050c     0 NOTYPE  LOCAL  DEFAULT   12 got_label
     36: 00000000     0 FILE    LOCAL  DEFAULT  ABS init.c 
     37: 00000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
     38: 00000534     0 FUNC    LOCAL  DEFAULT   12 deregister_tm_clones
     39: 0000058c     0 FUNC    LOCAL  DEFAULT   12 register_tm_clones
     40: 0002002c     1 OBJECT  LOCAL  DEFAULT   24 completed.0
     41: 000005f0     0 FUNC    LOCAL  DEFAULT   12 __do_global_dtors_aux
     42: 0001fec0     0 OBJECT  LOCAL  DEFAULT   18 __do_global_dtor[...]
     43: 00000660     0 FUNC    LOCAL  DEFAULT   12 frame_dummy
     44: 0001febc     0 OBJECT  LOCAL  DEFAULT   17 __frame_dummy_in[...]
     45: 00000000     0 FILE    LOCAL  DEFAULT  ABS main.c
     46: 00000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
     47: 00000984     0 OBJECT  LOCAL  DEFAULT   16 __FRAME_END__
     48: 00000000     0 FILE    LOCAL  DEFAULT  ABS
     49: 00000810     0 NOTYPE  LOCAL  DEFAULT   12 00000000.plt_pic[...]
     50: 00000800     0 NOTYPE  LOCAL  DEFAULT   12 00000000.plt_pic[...]
     51: 000007e0     0 NOTYPE  LOCAL  DEFAULT   12 00008000.got2.pl[...]
     52: 00000830     0 NOTYPE  LOCAL  DEFAULT   12 __glink_PLTresolve
     53: 0001fec0     0 NOTYPE  LOCAL  DEFAULT   17 __init_array_end
     54: 0001fff4     0 OBJECT  LOCAL  DEFAULT   21 _SDA_BASE_
     55: 000007d0     0 NOTYPE  LOCAL  DEFAULT   12 00008000.got2.pl[...]
     56: 0001fef0     0 OBJECT  LOCAL  DEFAULT   20 _DYNAMIC
     57: 0001febc     0 NOTYPE  LOCAL  DEFAULT   17 __init_array_start
     58: 00000820     0 NOTYPE  LOCAL  DEFAULT   12 __glink
     59: 000008ac     0 NOTYPE  LOCAL  DEFAULT   15 __GNU_EH_FRAME_HDR
     60: 0001fff4     0 OBJECT  LOCAL  DEFAULT   21 _GLOBAL_OFFSET_TABLE_
     61: 000007f0     0 NOTYPE  LOCAL  DEFAULT   12 00008000.got2.pl[...]
     62: 000004b0     0 FUNC    LOCAL  DEFAULT   11 _init
     63: 000007c4    12 FUNC    GLOBAL DEFAULT   12 __libc_csu_fini
     64: 00000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterT[...]
     65: 00020024     0 NOTYPE  WEAK   DEFAULT   23 data_start
     66: 00000000     0 FUNC    GLOBAL DEFAULT  UND printf@@GLIBC_2.4
     67: 00000000     0 FUNC    GLOBAL DEFAULT  UND world
     68: 0002002c     0 NOTYPE  GLOBAL DEFAULT   23 _edata
     69: 00000870     0 FUNC    GLOBAL HIDDEN    13 _fini
     70: 00000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@@[...]
     71: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND se-dynld
     72: 00000000     0 FUNC    GLOBAL DEFAULT  UND hello
     73: 00020024     0 NOTYPE  GLOBAL DEFAULT   23 __data_start
     74: 00000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     75: 00020028     0 OBJECT  GLOBAL HIDDEN    23 __dso_handle
     76: 0000089c     4 OBJECT  GLOBAL DEFAULT   14 _IO_stdin_used
     77: 00000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_mai[...]
     78: 000006c4   256 FUNC    GLOBAL DEFAULT   12 __libc_csu_init
     79: 00020030     0 NOTYPE  GLOBAL DEFAULT   24 _end
     80: 00000500    52 FUNC    GLOBAL DEFAULT   12 _start
     81: 0002002c     0 NOTYPE  GLOBAL DEFAULT   24 __bss_start
     82: 00000664    96 FUNC    GLOBAL DEFAULT   12 main
     83: 0002002c     0 OBJECT  GLOBAL HIDDEN    23 __TMC_END__
     84: 00000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMC[...]

Histogram for `.gnu.hash' 
bucket list length (total of 2 buckets):
  
Length  Number     of total  Coverage
       0  1          
50.0%)
       
1  1          50.0%)    100.0%

Version symbols section '.gnu.version' contains 11 entries:
  
Addr0x0000000000000338  Offset0x000338  Link(.dynsym)
   
000:   (*local*)       (*local*)       (*local*)       (GLIBC_2.4)
   
004:   (*local*)       (GLIBC_2.1.3)   (*local*)       (*local*)
   008:   
(GLIBC_2.0)     (*local*)       (*global*)

Version needs section '.gnu.version_r' contains 1 entry:
  
Addr0x0000000000000350  Offset0x000350  Link(.dynstr)
   
000000Version1  Filelibc.so.6  Cnt3
   0x0010
:   NameGLIBC_2.0  Flagsnone  Version4
   0x0020
:   NameGLIBC_2.1.3  Flagsnone  Version3
   0x0030
:   NameGLIBC_2.4  Flagsnone  Version2

Displaying notes found in
: .note.gnu.build-id
   Owner                Data size     Description
   GNU                  0x00000014    NT_GNU_BUILD_ID 
(unique build ID bitstring)
     
Build ID88d5b4a06f0423698e4f46d06c3518e7cc3bc3ac

Displaying notes found in
: .note.ABI-tag
   Owner                Data size     Description
   GNU                  0x00000010    NT_GNU_ABI_TAG 
(ABI version tag)
     
OSLinuxABI3.2.0


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


I don't know, maybe skateman is reading this and can answer that.

I will take a look at the binutils source and see, what i see

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


See User information
@all

I checked out the binutils from adtools and tried to get a grips about it. During the browsing of the patches, the following question came up:

Are the binutils actually used by other OSes (Amithon, MorphOS, AmigaOS 68k) or do they nower days have there own?

And an extra question. Is there a PPC HUNK object format active used? Because it seems that the first patch contains code for that.

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


See User information
@MightyMax
Today all oses like os3, aros and morphos have their own toolchains, and didnt use adtools anymore.

Half of year ago, i give a go and updated binutils for next version, and plan was to update step by step until reach a minimum version which support dwarf4 and stuff.

So i made next version of binutils works, binariescompiles and works, but due to that patch mess i just didnt find time to deal with proper commiting of changes (hope to do it soon than later)

But! The point is : when i start working on, i ask Sebastian (the current mantainer of adtools) why we need to keep that os3, aros and morphos code, if they long ago used their own toolchains, and he wascompletely agree to remove it all, for make better reading of code and easy to mantain. So, i was about to do so and together with new patches for next binutils commit it all, but was overflow with other projects, and didnt do so still.

Why i explain it all, its just to say to everyone that SBA1 completely ok with removing all other's oses code, and porting of binutils its not hard, just need time to be spend.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Qt 6 progress
Just popping in
Just popping in


See User information
@kas1e

Maybe you could somehow share the work you have done? Because getting rid of the not OS 4 specific stuff could make things easier.

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


See User information
@MightyMax
Of course can do so, but didn't remember if it was with or without deleting os3/mos/aros code (at least not from configure scripts for sure):

https://www.amigans.net/modules/newbb/ ... id=128803#forumpost128803

This patch just not in real adtools-path way, i just make it like this: have one original directory and another one with my changes and then just "diff -ru --new-file a b >binutls_2_24.patch"

But see the post i point out for more details and link on patch.

Maybe it's time to just do firstly only that : in the current binutils (at least in the binutils first) remove all os3/mos/aros code, and regenerate patches without (and not made for now bnutils switch, this one for later). So we will have just more readable code right now.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Qt 6 progress
Not too shy to talk
Not too shy to talk


See User information
@MigthyMax

don't know, maybe skateman is reading this and can answer that.

Binutils 2.35.1_4

URL
http://www.gnu.org/software/binutils/
Version 2.35.1_4
Architecture ppc
Licenses GPL-3.0-or-later
Install date Monday, 2 January 2023 16:29:00 GMT
Download Size 7602KB
Installed Size 33MB
Maintainer Enno Boland <gottox@voidlinux.org>

AmigaOne X5000 -> 2GHz / 16GB RAM / Radeon RX 550 / ATI X1950 / M-Audio 5.1 -> AmigaOS 4.1 FE / Linux / MorphOS
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the NET
Vampire V4SE TrioBoot
RPI4 AmiKit XE
Go to top

  Register To Post
« 1 ... 7 8 9 (10) 11 12 13 ... 20 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project