Who's Online |
155 user(s) are online ( 82 user(s) are browsing Forums)
Members: 2
Guests: 153
Georg, cygnusEd,
more...
|
|
Headlines |
-
amiarcadia.lha - emulation/gamesystem
Mar 28, 2024
-
losmalditosdemo.lha - game/adventure
Mar 26, 2024
-
libfreetype.lha - development/library/graphics
Mar 25, 2024
-
ign-addon-ods.lha - office/spreadsheet
Mar 25, 2024
-
meminfo.lha - utility/hardware
Mar 25, 2024
-
libsdl2_ttf.lha - development/library/graphics
Mar 24, 2024
-
thf.lha - game/fps
Mar 24, 2024
-
amigagpt.lha - network/chat
Mar 24, 2024
-
liba52.lha - development/library/audio
Mar 23, 2024
-
libsdl2_mixer.lha - development/library/audio
Mar 23, 2024
|
|
|
|
Binutils port
|
Posted on: 2023/1/10 11:16
#61
|
Just popping in
|
I'm started to apply all the patches from the binutils adtools ports to the current main development trunk of the binutils. For that I setup a temp. repository on github. I tried to only take over all changes that are needed for AmigaOS ELF. Omitting Morphos, AROS, AmigaOS Hunk. Because there are parts which changed a lot I had more or less manually apply all patches. Some patches weren't needed any more, others were straight forward, and others hat to be adapted in that way, that they merely are recognizable anymore. Id doesn't compile yet, mainly i have issues to adapt the apaches for obycopy.c and the build system for the gas part. Maybe someone can help? The flowing patches haven't been yet manually applied, because I'm unsure if they are really still needed: * 0010-Fix-Wimplicit-fallthrough-warnings.patch Mainly because the most of them just change the comment, but some even add break statement, which might have unwanted side effects, * 0013-Don-t-emit-dynamic-relocations-for-data-symbols.patch I'm unable to match it with the new structure of the binutils.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/9 13:50
#62
|
Just popping in
|
@elfpipe Quote: In the current elf.library implementation, the easiest way of meeting this requirement, is to do a default lookup, which will always result in pointer equality. Since the .plt entry is private to the main app (or the specific shared object), there is no way of having pointer equality, when the entry points to the .plt entry. And the only known cases of a non-zero st_value are the ones, where st_value points to .plt. My personal opinion is to let the elf.library only perform an look up is the value is zero, and to fix binutils to put there a zero. Does binutils put a zero in if the "!" is removed from the if clause?
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/9 13:48
#63
|
Just popping in
|
@elfpipe Quote: Actually, when looking at the original non-amiga text (as found in the patches) :
if (!h->pointer_equality_needed)
- sym->st_value = 0;
This is a bit mysterious. From my current perspective, this looks like a bug. The cases, that require pointer equality, are exactly the cases, where we need the st_value parameter to be zero. So this might be just a case of a '!' inserted in the wrong place. It will be interesting to know, what the updated binutils source says in this place.
It's still the same in the current main of binutils. And even for me it looks like an bug. I missed the "!" as i found the location. For me it was obvious that there isn't a "!".
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/8 15:34
#64
|
Just popping in
|
@elfpipe Quote: IF we are to implement the ABI text and allow for linking using the st_value attribute for UNDEF entries, then we still need to figure out, why the 'world' symbol comes out non-zero in the example. Simply uncommenting the line with st_value = 0 doesn't solve that part of the problem. Currently no idea why it doesn't solve it, except a general issue in the used binutils version.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/8 13:29
#65
|
Just popping in
|
@kas1e Quote: Speaking of which, vbcc do have option -baserel32os4 to enable such data addressing. In the GCC, back in the past, we do use -mbaserel or something, but, issue there that since gcc4.x or something, this was deprecated silently and done with it.
Through, again, i don't know how it all apply to our sobjs issue which we faced there, but at least some bits of info about those relocations sections can help the whole picture. It doesn't have anything to do with the sobjs issues. It just curiosity on my side. An silently done is very interesting because the implementation of the relocs in the binutils apaches are more less uncommented like this:
#if 0
case R_PPC_AMIGAOS_BREL:
case R_PPC_AMIGAOS_BREL_HI:
case R_PPC_AMIGAOS_BREL_LO:
case R_PPC_AMIGAOS_BREL_HA:
{
if (data_section == NULL)
data_section = bfd_get_section_by_name (output_bfd, ".data");
if (sec)
{
const char *name = bfd_get_section_name (abfd, sec->output_section);
if (strcmp (name, ".sdata") != 0
&& strcmp (name, ".sbss") != 0
&& strcmp (name, ".data") != 0
&& strcmp (name, ".bss") != 0
&& strncmp (name, ".ctors", 6) != 0
&& strncmp (name, ".dtors", 6) != 0)
{
(*_bfd_error_handler) (_("%s: The target (%s) of a %s relocation is in the wrong output section (%s)"),
input_bfd,
sym_name,
howto->name,
name);
}
}
addend = addend - data_section->vma;
if (r_type == R_PPC_AMIGAOS_BREL_HA)
addend += ((relocation + addend) & 0x8000) << 1;
}
break;
#endif
So my question, in the progress to adapt the binutils patches to the latest binutils master, should they be again enabled?
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/8 13:23
#66
|
Just popping in
|
@elfpipe Quote: What I have done is to build elf.library to default to symbol lookup for UND symbols. I won't go for the general way to perform a lookup. As the ABI states, it should only be made if the value of the symbol is zero and a UNDEF function. It explicitly states that if it if an UNDEF function and value is none zero, use the value. There might b use cases where the linker is able to pre calculated an address which should be used, which we haven't on our radar. So i think the solution is a combination of a new elf.library and a fixed linker. I even think that the changes made to the linker (as pointed out) has only been introduced, to workaround a problem in past. Quote: Constructur issue. Any takers? I'm so deep now into the linker stuff i will take a look.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/6 16:03
#67
|
Just popping in
|
@elfpipe Quote: If an updated binutils could be produced in an official format, it would be a step in the right direction. I'M currently using kas1e 2.24 patch from his provided links, and trying to adapt it on the master of the binutils. I have a question, which maybe can enlighten me. The AmigaOS ppc platform defines four additional reloctaions:
R_PPC_AMIGAOS_BREL
R_PPC_AMIGAOS_BREL_LO
R_PPC_AMIGAOS_BREL_HI
R_PPC_AMIGAOS_BREL_HA
Is there any documentation out there for them? And are they really used by real binaries?
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/6 15:57
#68
|
Just popping in
|
@elfpipe Quote: 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. I found the line 9345 int the file you mention causing, that the value in the symbols isn't zero:
...
9328 if (!h->def_regular)
9329 {
9330 /* Mark the symbol as undefined, rather than as
9331 defined in the .plt section. Leave the value if
9332 there were any relocations where pointer equality
9333 matters (this is a clue for the dynamic linker, to
9334 make function pointer comparisons work between an
9335 application and shared library), otherwise set it
9336 to zero. */
9337 sym->st_shndx = SHN_UNDEF;
9338 if (!h->pointer_equality_needed)
9339 {
9340 /* THF: This is peculiar. The compiler generates a R_PPC_REL24 for externally referenced
9341 * symbols impoted from libc.so. Relocation in elf.library requires the symbol to have it's .plt
9342 * stub value, but the linker specifically clears the value to 0, resulting in run-time
9343 * errors when the binary tries to call libc functions.
9344 */
9345 // sym->st_value = 0;
9346 }
9347 else if (!h->ref_regular_nonweak)
...
That should probably be handled more sophisticated.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/1/5 10:07
#69
|
Just popping in
|
@kas1e Quote: And, i didn't add other patches at the moment, as some of them look like may not need it (like 0002-Fixed-errors-occuring-with-more-recent-versions-of-t.patch, i not sure how to check where issues come), and other ones as well, but I assume those ones are easy enough to add. That patch only fixes syntax errors in the 'texi' files, provided by the Port for documenting the support for the hunk object file format. thus can be ignored if going for a OS4 only target binutils. Even the added amiga.texi amigalink.texi files can be omitted, like the modification on other texi files. BTW you could check these files, if you generate the documentation, which as long i know isn't auto, automatically generated during an 'make install' call.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/4 16:57
#70
|
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.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/4 14:56
#71
|
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.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/4 13:17
#72
|
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
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/4 8:05
#73
|
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.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2023/1/2 9:42
#74
|
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.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2022/12/31 13:33
#75
|
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.
|
|
|
|
Re: AmiStore is broken for me
|
Posted on: 2022/12/31 12:45
#76
|
Just popping in
|
@Nostromo I had/have the same issue. My login just don't work with the AmiStore application. Actually it's not true, it work two times, but than it "threw" me out during adding stuff to the cart, etc. I resolve it with a re-implementing of the AmiStore application in java. You can used it to buy stuff etc, but with the following premise: My java implementation cannot download what you buy/bought. The download has to be done with Updater application on an Amiga. And to be sure that it works, you must be able to login with your account on the AmiSphere application in the prefs directory.
|
|
|
|
Re: Qt 6 progress
|
Posted on: 2022/12/30 12:51
#77
|
Just popping in
|
After reading an article about how linker and how dynamic loading is realized in the elf format, i thought about you problem. My first thought about your problem with the different address of the method, muts be that you get in the dynamic linked app, the address of the stub method of the PLT. So i started to investigate the C example at issue 109. First i took a look at the static linked app: Quote: [0]>Work:Home/Workspaces/109>objdump -d app_static
app_static: file format elf32-amigaos
Disassembly of section .text:
01000074 <_start>: 1000074: 94 21 ff b0 stwu r1,-80(r1) 1000078: 7c 08 02 a6 mflr r0 100007c: 3d 20 01 02 lis r9,258 1000080: 3d 40 01 01 lis r10,257 1000084: 90 aa 00 28 stw r5,40(r10) 1000088: 90 01 00 54 stw r0,84(r1) 100008c: 93 e1 00 4c stw r31,76(r1) 1000090: 93 41 00 38 stw r26,56(r1) 1000094: 7d ba 6b 78 mr r26,r13 1000098: 39 a9 80 18 addi r13,r9,-32744 100009c: 83 e5 02 78 lwz r31,632(r5) 10000a0: 93 01 00 30 stw r24,48(r1) 10000a4: 7c 98 23 78 mr r24,r4 10000a8: 81 3f 00 3c lwz r9,60(r31) 10000ac: 93 21 00 34 stw r25,52(r1) 10000b0: 7c 79 1b 78 mr r25,r3 10000b4: 7f e3 fb 78 mr r3,r31 10000b8: 7d 29 03 a6 mtctr r9 10000bc: 93 81 00 40 stw r28,64(r1) 10000c0: 93 c1 00 48 stw r30,72(r1) 10000c4: 4e 80 04 21 bctrl 10000c8: 81 3f 01 a8 lwz r9,424(r31) 10000cc: 3d 40 01 01 lis r10,257 10000d0: 3c 80 01 00 lis r4,256 10000d4: 93 ea 00 20 stw r31,32(r10) 10000d8: 7f e3 fb 78 mr r3,r31 10000dc: 38 84 10 00 addi r4,r4,4096 10000e0: 38 a0 00 32 li r5,50 10000e4: 7d 29 03 a6 mtctr r9 10000e8: 4e 80 04 21 bctrl 10000ec: 7c 7c 1b 79 mr. r28,r3 10000f0: 41 c2 03 50 beq- 1000440 <_start+0x3cc> 10000f4: 81 3f 01 c0 lwz r9,448(r31) 10000f8: 3f c0 01 00 lis r30,256 10000fc: 38 e0 00 00 li r7,0 1000100: 3b de 10 10 addi r30,r30,4112 1000104: 93 a1 00 44 stw r29,68(r1) 1000108: 38 c0 00 01 li r6,1 100010c: 7f c5 f3 78 mr r5,r30 1000110: 7f 84 e3 78 mr r4,r28 1000114: 7f e3 fb 78 mr r3,r31 1000118: 7d 29 03 a6 mtctr r9 100011c: 4e 80 04 21 bctrl 1000120: 7c 7d 1b 79 mr. r29,r3 1000124: 41 c2 03 44 beq- 1000468 <_start+0x3f4> 1000128: 81 5d 00 10 lwz r10,16(r29) 100012c: 3d 20 01 01 lis r9,257 1000130: 3c 80 01 00 lis r4,256 1000134: 93 61 00 3c stw r27,60(r1) 1000138: 3f 60 01 01 lis r27,257 100013c: 38 a0 00 34 li r5,52 1000140: 91 49 00 2c stw r10,44(r9) 1000144: 38 84 10 18 addi r4,r4,4120 1000148: 7f e3 fb 78 mr r3,r31 100014c: 81 3f 01 a8 lwz r9,424(r31) 1000150: 93 bb 00 30 stw r29,48(r27) 1000154: 7d 29 03 a6 mtctr r9 1000158: 4e 80 04 21 bctrl 100015c: 7c 7d 1b 79 mr. r29,r3 1000160: 41 c2 01 c0 beq- 1000320 <_start+0x2ac> 1000164: 81 3f 01 c0 lwz r9,448(r31) 1000168: 38 e0 00 00 li r7,0 100016c: 38 c0 00 01 li r6,1 1000170: 7f c5 f3 78 mr r5,r30 1000174: 7f a4 eb 78 mr r4,r29 1000178: 7f e3 fb 78 mr r3,r31 100017c: 7d 29 03 a6 mtctr r9 1000180: 4e 80 04 21 bctrl 1000184: 7c 7c 1b 79 mr. r28,r3 1000188: 41 c2 01 84 beq- 100030c <_start+0x298> 100018c: 3d 20 01 01 lis r9,257 1000190: 92 c1 00 28 stw r22,40(r1) 1000194: 3d 00 01 00 lis r8,256 1000198: 81 49 00 38 lwz r10,56(r9) 100019c: 3d 20 00 34 lis r9,52 10001a0: 39 08 10 4c addi r8,r8,4172 10001a4: 92 e1 00 2c stw r23,44(r1) 10001a8: 61 29 00 14 ori r9,r9,20 10001ac: 3b a0 00 00 li r29,0 10001b0: 80 fc 00 10 lwz r7,16(r28) 10001b4: 55 4a 07 fe clrlwi r10,r10,31 10001b8: 7f 9d 48 40 cmplw cr7,r29,r9 10001bc: 40 dc 00 08 bge- cr7,10001c4 <_start+0x150> 10001c0: 7d 3d 4b 78 mr r29,r9 10001c4: 85 28 00 04 lwzu r9,4(r8) 10001c8: 2f 89 00 00 cmpwi cr7,r9,0 10001cc: 40 fe ff ec bne- cr7,10001b8 <_start+0x144> 10001d0: 81 27 00 14 lwz r9,20(r7) 10001d4: 3d 00 01 01 lis r8,257 10001d8: 93 88 00 18 stw r28,24(r8) 10001dc: 3d 29 ff cc addis r9,r9,-52 10001e0: 39 29 ff d9 addi r9,r9,-39 10001e4: 2b 89 ff f7 cmplwi cr7,r9,65527 10001e8: 41 dd 00 14 bgt- cr7,10001fc <_start+0x188> 10001ec: 3d 20 00 34 lis r9,52 10001f0: 61 29 00 26 ori r9,r9,38 10001f4: 7f 9d 48 40 cmplw cr7,r29,r9 10001f8: 41 dd 01 5c bgt- cr7,1000354 <_start+0x2e0> 10001fc: 3d 00 01 01 lis r8,257 1000200: 3d 20 01 01 lis r9,257 1000204: 39 08 00 08 addi r8,r8,8 1000208: 39 29 00 00 addi r9,r9,0 100020c: 38 c0 00 01 li r6,1 1000210: 91 01 00 10 stw r8,16(r1) 1000214: 3c 60 01 01 lis r3,257 1000218: 91 21 00 0c stw r9,12(r1) 100021c: 3d 00 01 00 lis r8,256 1000220: 3c e0 01 01 lis r7,257 1000224: 90 c1 00 08 stw r6,8(r1) 1000228: 3c c0 01 01 lis r6,257 100022c: 7f 05 c3 78 mr r5,r24 1000230: 81 23 00 34 lwz r9,52(r3) 1000234: 7f 24 cb 78 mr r4,r25 1000238: 7f a3 eb 78 mr r3,r29 100023c: 39 08 04 c0 addi r8,r8,1216 1000240: 38 e7 00 1c addi r7,r7,28 1000244: 81 7c 00 50 lwz r11,80(r28) 1000248: 38 c6 00 24 addi r6,r6,36 100024c: 7d 69 03 a6 mtctr r11 1000250: 4e 80 04 21 bctrl 1000254: 7c 7e 1b 78 mr r30,r3 1000258: 81 3f 01 c8 lwz r9,456(r31) 100025c: 7f 84 e3 78 mr r4,r28 1000260: 7f e3 fb 78 mr r3,r31 1000264: 83 bc 00 10 lwz r29,16(r28) 1000268: 7d 29 03 a6 mtctr r9 100026c: 4e 80 04 21 bctrl 1000270: 81 3f 01 ac lwz r9,428(r31) 1000274: 7f a4 eb 78 mr r4,r29 1000278: 7f e3 fb 78 mr r3,r31 100027c: 7d 29 03 a6 mtctr r9 1000280: 4e 80 04 21 bctrl 1000284: 81 3b 00 30 lwz r9,48(r27) 1000288: 82 c1 00 28 lwz r22,40(r1) 100028c: 2f 89 00 00 cmpwi cr7,r9,0 1000290: 82 e1 00 2c lwz r23,44(r1) 1000294: 41 de 00 b4 beq- cr7,1000348 <_start+0x2d4> 1000298: 81 5f 01 c8 lwz r10,456(r31) 100029c: 7d 24 4b 78 mr r4,r9 10002a0: 7f e3 fb 78 mr r3,r31 10002a4: 83 a9 00 10 lwz r29,16(r9) 10002a8: 7d 49 03 a6 mtctr r10 10002ac: 4e 80 04 21 bctrl 10002b0: 81 3f 01 ac lwz r9,428(r31) 10002b4: 7f a4 eb 78 mr r4,r29 10002b8: 7f e3 fb 78 mr r3,r31 10002bc: 7d 29 03 a6 mtctr r9 10002c0: 4e 80 04 21 bctrl 10002c4: 83 61 00 3c lwz r27,60(r1) 10002c8: 83 a1 00 44 lwz r29,68(r1) 10002cc: 81 3f 00 40 lwz r9,64(r31) 10002d0: 7f e3 fb 78 mr r3,r31 10002d4: 7d 29 03 a6 mtctr r9 10002d8: 4e 80 04 21 bctrl 10002dc: 80 01 00 54 lwz r0,84(r1) 10002e0: 7f c3 f3 78 mr r3,r30 10002e4: 7f 4d d3 78 mr r13,r26 10002e8: 83 01 00 30 lwz r24,48(r1) 10002ec: 83 21 00 34 lwz r25,52(r1) 10002f0: 7c 08 03 a6 mtlr r0 10002f4: 83 41 00 38 lwz r26,56(r1) 10002f8: 83 81 00 40 lwz r28,64(r1) 10002fc: 83 c1 00 48 lwz r30,72(r1) 1000300: 83 e1 00 4c lwz r31,76(r1) 1000304: 38 21 00 50 addi r1,r1,80 1000308: 4e 80 00 20 blr 100030c: 81 3f 01 ac lwz r9,428(r31) 1000310: 7f a4 eb 78 mr r4,r29 1000314: 7f e3 fb 78 mr r3,r31 1000318: 7d 29 03 a6 mtctr r9 100031c: 4e 80 04 21 bctrl 1000320: 81 3f 02 3c lwz r9,572(r31) 1000324: 3c 80 00 03 lis r4,3 1000328: 7f e3 fb 78 mr r3,r31 100032c: 60 84 80 0e ori r4,r4,32782 1000330: 3b c0 00 14 li r30,20 1000334: 7d 29 03 a6 mtctr r9 1000338: 4e 80 04 21 bctrl 100033c: 81 3b 00 30 lwz r9,48(r27) 1000340: 2f 89 00 00 cmpwi cr7,r9,0 1000344: 40 fe ff 54 bne- cr7,1000298 <_start+0x224> 1000348: 83 61 00 3c lwz r27,60(r1) 100034c: 83 a1 00 44 lwz r29,68(r1) 1000350: 4b ff ff 7c b 10002cc <_start+0x258> 1000354: 81 3f 01 a8 lwz r9,424(r31) 1000358: 3c 80 01 00 lis r4,256 100035c: 38 a0 00 32 li r5,50 1000360: 38 84 10 28 addi r4,r4,4136 1000364: 7f e3 fb 78 mr r3,r31 1000368: 91 41 00 18 stw r10,24(r1) 100036c: 7d 29 03 a6 mtctr r9 1000370: 4e 80 04 21 bctrl 1000374: 7c 76 1b 79 mr. r22,r3 1000378: 41 c2 01 28 beq- 10004a0 <_start+0x42c> 100037c: 81 3f 01 c0 lwz r9,448(r31) 1000380: 7f c5 f3 78 mr r5,r30 1000384: 38 e0 00 00 li r7,0 1000388: 38 c0 00 01 li r6,1 100038c: 7e c4 b3 78 mr r4,r22 1000390: 7f e3 fb 78 mr r3,r31 1000394: 7d 29 03 a6 mtctr r9 1000398: 4e 80 04 21 bctrl 100039c: 81 41 00 18 lwz r10,24(r1) 10003a0: 7c 77 1b 79 mr. r23,r3 10003a4: 41 82 00 e8 beq- 100048c <_start+0x418> 10003a8: 3d 00 01 01 lis r8,257 10003ac: 3d 20 01 01 lis r9,257 10003b0: 80 77 00 10 lwz r3,16(r23) 10003b4: 39 08 00 08 addi r8,r8,8 10003b8: 39 29 00 00 addi r9,r9,0 10003bc: 38 a0 00 01 li r5,1 10003c0: 91 01 00 10 stw r8,16(r1) 10003c4: 3c c0 01 01 lis r6,257 10003c8: 91 21 00 0c stw r9,12(r1) 10003cc: 3c e0 01 01 lis r7,257 10003d0: 3d 20 01 01 lis r9,257 10003d4: 90 a1 00 08 stw r5,8(r1) 10003d8: 3d 00 01 00 lis r8,256 10003dc: 7f 05 c3 78 mr r5,r24 10003e0: 7f 24 cb 78 mr r4,r25 10003e4: 90 66 00 24 stw r3,36(r6) 10003e8: 39 08 04 c0 addi r8,r8,1216 10003ec: 92 e7 00 1c stw r23,28(r7) 10003f0: 38 c0 00 00 li r6,0 10003f4: 38 e0 00 00 li r7,0 10003f8: 81 7c 00 50 lwz r11,80(r28) 10003fc: 7f a3 eb 78 mr r3,r29 1000400: 81 29 00 34 lwz r9,52(r9) 1000404: 7d 69 03 a6 mtctr r11 1000408: 4e 80 04 21 bctrl 100040c: 81 3f 01 c8 lwz r9,456(r31) 1000410: 7e e4 bb 78 mr r4,r23 1000414: 7c 7e 1b 78 mr r30,r3 1000418: 7f e3 fb 78 mr r3,r31 100041c: 83 b7 00 10 lwz r29,16(r23) 1000420: 7d 29 03 a6 mtctr r9 1000424: 4e 80 04 21 bctrl 1000428: 81 3f 01 ac lwz r9,428(r31) 100042c: 7f a4 eb 78 mr r4,r29 1000430: 7f e3 fb 78 mr r3,r31 1000434: 7d 29 03 a6 mtctr r9 1000438: 4e 80 04 21 bctrl 100043c: 4b ff fe 1c b 1000258 <_start+0x1e4> 1000440: 3d 20 01 01 lis r9,257 1000444: 93 89 00 30 stw r28,48(r9) 1000448: 81 3f 02 3c lwz r9,572(r31) 100044c: 3c 80 00 03 lis r4,3 1000450: 7f e3 fb 78 mr r3,r31 1000454: 60 84 80 0c ori r4,r4,32780 1000458: 3b c0 00 14 li r30,20 100045c: 7d 29 03 a6 mtctr r9 1000460: 4e 80 04 21 bctrl 1000464: 4b ff fe 68 b 10002cc <_start+0x258> 1000468: 81 3f 01 ac lwz r9,428(r31) 100046c: 7f 84 e3 78 mr r4,r28 1000470: 7f e3 fb 78 mr r3,r31 1000474: 7d 29 03 a6 mtctr r9 1000478: 4e 80 04 21 bctrl 100047c: 3d 20 01 01 lis r9,257 1000480: 93 a9 00 30 stw r29,48(r9) 1000484: 83 a1 00 44 lwz r29,68(r1) 1000488: 4b ff ff c0 b 1000448 <_start+0x3d4> 100048c: 81 3f 01 ac lwz r9,428(r31) 1000490: 7e c4 b3 78 mr r4,r22 1000494: 7f e3 fb 78 mr r3,r31 1000498: 7d 29 03 a6 mtctr r9 100049c: 4e 80 04 21 bctrl 10004a0: 81 3f 02 3c lwz r9,572(r31) 10004a4: 3c 80 00 03 lis r4,3 10004a8: 7f e3 fb 78 mr r3,r31 10004ac: 60 84 80 07 ori r4,r4,32775 10004b0: 3b c0 00 14 li r30,20 10004b4: 7d 29 03 a6 mtctr r9 10004b8: 4e 80 04 21 bctrl 10004bc: 4b ff fd 9c b 1000258 <_start+0x1e4>
010004c0 <main>: 10004c0: 94 21 ff f0 stwu r1,-16(r1) 10004c4: 7c 08 02 a6 mflr r0 10004c8: 93 e1 00 0c stw r31,12(r1) 10004cc: 90 01 00 14 stw r0,20(r1) 10004d0: 7c 3f 0b 78 mr r31,r1 10004d4: 48 00 00 41 bl 1000514 <hello> 10004d8: 3d 20 01 00 lis r9,256 10004dc: 38 69 10 34 addi r3,r9,4148 10004e0: 3d 20 01 00 lis r9,256 10004e4: 38 89 05 68 addi r4,r9,1384 10004e8: 4c c6 31 82 crclr 4*cr1+eq 10004ec: 48 00 00 99 bl 1000584 <printf> 10004f0: 38 00 00 00 li r0,0 10004f4: 7c 03 03 78 mr r3,r0 10004f8: 81 61 00 00 lwz r11,0(r1) 10004fc: 80 0b 00 04 lwz r0,4(r11) 1000500: 7c 08 03 a6 mtlr r0 1000504: 83 eb ff fc lwz r31,-4(r11) 1000508: 7d 61 5b 78 mr r1,r11 100050c: 4e 80 00 20 blr 1000510: 00 01 7a e0 .long 0x17ae0
01000514 <hello>: 1000514: 94 21 ff f0 stwu r1,-16(r1) 1000518: 7c 08 02 a6 mflr r0 100051c: 93 c1 00 08 stw r30,8(r1) 1000520: 93 e1 00 0c stw r31,12(r1) 1000524: 90 01 00 14 stw r0,20(r1) 1000528: 7c 3f 0b 78 mr r31,r1 100052c: 42 9f 00 05 bcl- 20,4*cr7+so,1000530 <hello+0x1c> 1000530: 7f c8 02 a6 mflr r30 1000534: 80 1e ff e0 lwz r0,-32(r30) 1000538: 7f c0 f2 14 add r30,r0,r30 100053c: 80 7e 80 00 lwz r3,-32768(r30) 1000540: 80 9e 80 04 lwz r4,-32764(r30) 1000544: 4c c6 31 82 crclr 4*cr1+eq 1000548: 48 00 00 3d bl 1000584 <printf> 100054c: 81 61 00 00 lwz r11,0(r1) 1000550: 80 0b 00 04 lwz r0,4(r11) 1000554: 7c 08 03 a6 mtlr r0 1000558: 83 cb ff f8 lwz r30,-8(r11) 100055c: 83 eb ff fc lwz r31,-4(r11) 1000560: 7d 61 5b 78 mr r1,r11 1000564: 4e 80 00 20 blr
01000568 <world>: 1000568: 94 21 ff f0 stwu r1,-16(r1) 100056c: 93 e1 00 08 stw r31,8(r1) 1000570: 7c 3f 0b 78 mr r31,r1 1000574: 81 61 00 00 lwz r11,0(r1) 1000578: 83 eb ff f8 lwz r31,-8(r11) 100057c: 7d 61 5b 78 mr r1,r11 1000580: 4e 80 00 20 blr
01000584 <printf>: 1000584: 39 80 04 b0 li r12,1200 1000588: 48 00 00 04 b 100058c <__NewlibCall>
0100058c <__NewlibCall>: 100058c: 3d 60 01 01 lis r11,257 1000590: 80 0b 00 18 lwz r0,24(r11) 1000594: 7d 6c 00 2e lwzx r11,r12,r0 1000598: 7d 69 03 a6 mtctr r11 100059c: 4e 80 04 20 bctr
The interesting part is address 10004e0 & 10004e4; Quote: 10004e0: 3d 20 01 00 lis r9,256 10004e4: 38 89 05 68 addi r4,r9,1384
Performing the these two operations result the following address 0x010000568, which is the wanted address of the world method: Quote: 01000568 <world>: 1000568: 94 21 ff f0 stwu r1,-16(r1) 100056c: 93 e1 00 08 stw r31,8(r1) 1000570: 7c 3f 0b 78 mr r31,r1 1000574: 81 61 00 00 lwz r11,0(r1) 1000578: 83 eb ff f8 lwz r31,-8(r11) 100057c: 7d 61 5b 78 mr r1,r11 1000580: 4e 80 00 20 blr
To have the correct address of the world method in the main method, the flowing relocation were present in the object file fr the main.c. The main.o file isn't build by the makefile , you need to build it by yourself with cc -o app_static.o -c main.c -L. -lhello -athread=single<[font=Haettenschweiler]world: Quote: [0]>Work:Home/Workspaces/109>readelf -r app_static.o
Relocation section '.rela.text' at offset 0x354 contains 6 entries: Offset Info Type Sym.Value Sym. Name + Addend 00000014 0000080a R_PPC_REL24 00000000 hello + 0 0000001a 00000906 R_PPC_ADDR16_HA 00000000 world + 0 0000001e 00000904 R_PPC_ADDR16_LO 00000000 world + 0 00000022 00000506 R_PPC_ADDR16_HA 00000000 .rodata + 0 00000026 00000504 R_PPC_ADDR16_LO 00000000 .rodata + 0 0000002c 00000a0a R_PPC_REL24 00000000 printf + 0
And its the second and third relocation, which is responsible for correct behavior in the static linking. Thus my thought was that the relocation must be wrong in the dynamic variant. So taking a look at the relocation of dynamic linked app should reveal it: Quote: [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
But as we can see the second and third last relocation are just the relocation needed for the main method to get the address of the world method and not as i thought the PLT stub function. You can verify that the relocation addresse the same instruction in the main method, with an objdump -d app_dyn. As a conclusion, i don't think that it is an bug in the compiler. I think that it is a bug in the OS and how dynamic linkage of so files is implemented. I couldn't find ayn deeper information how dynamic so linking in AmigaOS 4 is realized, os it my conclusion is just a vague hint that the cause lies in the OS. But maybe someone more involved in the OS part can pick that and investigate it further,
|
|
|
|
Re: Command "Dir" 54.5 (c) 2022 AmigaKit, command not working from AUX:
|
Posted on: 2022/12/3 18:05
#78
|
Just popping in
|
@LiveForIt I added Quote: to my user-startup too, but hwo does it help with Quote: gfx is lockuped up.. (its also useful for copy & paste.) I don't see an effect or differnce after a reboot. Shouldn't there pop up somewhere a shell additional to the workbench?
|
|
|
|
Re: SDK 54.16
|
Posted on: 2022/12/1 9:21
#79
|
Just popping in
|
@walkero Quote: I actually have one for personal use. The thing is that if something is going to be released by someone has to have some minimum standards, i.e. that the libs are created for both clib2 and newlib, they pass all the tests that are possible to pass etc. To do that you have either to do it yourself for all these libraries, or the people who port them have to follow those standards. Again a big task to do, but if anyone would like to step up for it would be awesome. Would it be smart to just document that, what a developer hast to fulfill, to make as easy as possible for you to include it in the SDK. Including the test cases, because there might more than me that have no clue what actually a linked library an AmigaOS has to "support" be be best usable by other developers.
|
|
|
|
Re: Porting to AmigaOS4 thread
|
Posted on: 2022/9/27 16:44
#80
|
Just popping in
|
@Raziel In your case, you have to migrate the code to use the now official method to create an IORequest
timerio = IExec->AllocSysObjectTags(ASOT_IOREQUEST,
ASOIOR_Size, sizeof(struct IORequest),
TAG_DONE);
and for freeing (deleting)
IExec->FreeSysObject(ASOT_LIST,(APTR)timerio );
For MsgPprt it's the same pattern, like ASOT_PORT. The issue with the TimerIFace, i have no currently no clue
|
|
|
|