Qt 6 progress

	Bottom Previous Topic Next Topic
Register To Post

« 1 ... 7 8 9 (10) 11 12 13 ... 21 »

elfpipe

Re: Qt 6 progress

Posted on: 2022/12/30 14:42 #181

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?

MigthyMax

Re: Qt 6 progress

Posted on: 2022/12/31 13:33 #182

Just popping in

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

elfpipe

Re: Qt 6 progress

Posted on: 2022/12/31 16:54 #183

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.

elfpipe

Re: Qt 6 progress

Posted on: 2022/12/31 17:04 #184

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

Capehill

Re: Qt 6 progress

Posted on: 2023/1/1 13:36 #185

Just can't stay away

@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.o -c lib.c -fPIC

    $(CC) -o libf.so lib.o -shared

    ar cruv  libf.a lib.o

    ranlib libf.a 

    $(CC) -o test_dyn main.c -use-dynld -L. -lf -athread=native 

    $(CC) -o test_static main.c -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

elfpipe

Re: Qt 6 progress

Posted on: 2023/1/1 15:39 #186

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

elfpipe

Re: Qt 6 progress

Posted on: 2023/1/1 16:21 #187

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.

afxgroup

Re: Qt 6 progress

Posted on: 2023/1/2 8:14 #188

Amigans Defender

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

MigthyMax

Re: Qt 6 progress

Posted on: 2023/1/2 9:42 #189

Just popping in

@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    1 

     2: 01000108     0 SECTION LOCAL  DEFAULT    2 

     3: 01000150     0 SECTION LOCAL  DEFAULT    3 

     4: 01000220     0 SECTION LOCAL  DEFAULT    4 

     5: 010002b8     0 SECTION LOCAL  DEFAULT    5 

     6: 010002d0     0 SECTION LOCAL  DEFAULT    6 

     7: 010002f4     0 SECTION LOCAL  DEFAULT    7 

     8: 01001000     0 SECTION LOCAL  DEFAULT    9 

     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  Sym. Name + 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  Sym. Name + 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  Sym. Name + 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.

elfpipe

Re: Qt 6 progress

Posted on: 2023/1/2 11:45 #190

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!

elfpipe

Re: Qt 6 progress

Posted on: 2023/1/2 11:54 #191

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

Capehill

Re: Qt 6 progress

Posted on: 2023/1/2 18:59 #192

Just can't stay away

@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

MigthyMax

Re: Qt 6 progress

Posted on: 2023/1/4 8:05 #193

Just popping in

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

elfpipe

Re: Qt 6 progress

Posted on: 2023/1/4 11:25 #194

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

MigthyMax

Re: Qt 6 progress

Posted on: 2023/1/4 13:17 #195

Just popping in

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

  Addr: 0x0000000000000338  Offset: 0x000338  Link: 5 (.dynsym)

   000:   0 (*local*)       0 (*local*)       0 (*local*)       2 (GLIBC_2.4)

   004:   0 (*local*)       3 (GLIBC_2.1.3)   0 (*local*)       0 (*local*)

   008:   4 (GLIBC_2.0)     0 (*local*)       1 (*global*)



Version needs section '.gnu.version_r' contains 1 entry:

  Addr: 0x0000000000000350  Offset: 0x000350  Link: 6 (.dynstr)

   000000: Version: 1  File: libc.so.6  Cnt: 3

   0x0010:   Name: GLIBC_2.0  Flags: none  Version: 4

   0x0020:   Name: GLIBC_2.1.3  Flags: none  Version: 3

   0x0030:   Name: GLIBC_2.4  Flags: none  Version: 2



Displaying notes found in: .note.gnu.build-id

   Owner                Data size     Description

   GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)

     Build ID: 88d5b4a06f0423698e4f46d06c3518e7cc3bc3ac



Displaying notes found in: .note.ABI-tag

   Owner                Data size     Description

   GNU                  0x00000010    NT_GNU_ABI_TAG (ABI version tag)

     OS: Linux, ABI: 3.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

MigthyMax

Re: Qt 6 progress

Posted on: 2023/1/4 14:56 #196

Just popping in

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

kas1e

Re: Qt 6 progress

Posted on: 2023/1/4 15:46 #197

Home away from home

@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

MigthyMax

Re: Qt 6 progress

Posted on: 2023/1/4 16:57 #198

Just popping in

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

kas1e

Re: Qt 6 progress

Posted on: 2023/1/4 17:55 #199

Home away from home

@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

Skateman

Re: Qt 6 progress

Posted on: 2023/1/4 18:21 #200

Not too shy to talk

@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 / PiStorm CM4 / SD HDD / WifiPi connected to the NET
Vampire V4SE TrioBoot
RPI4 AmiKit XE

Register To Post	« 1 ... 7 8 9 (10) 11 12 13 ... 21 »
	Top Previous Topic Next Topic

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