Who's Online |
88 user(s) are online ( 51 user(s) are browsing Forums)
Members: 0
Guests: 88
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
|
|
|
|
Re: PCI device memory from BAR under qemu alwys zero
|
Posted on: 2023/9/13 16:10
#21
|
Just popping in
|
@balaton
I read multiple times what you wrote and even found bit and pieces in the source of bboot. But I still no clue who and where to adopt the bar truncation in my setup with bboot and initrd Kickstart.zip file. Any example anywhere (expect as Hans mention buried deep done in the mention thread)
|
|
|
|
Re: PCI device memory from BAR under qemu alwys zero
|
Posted on: 2023/9/13 10:09
#22
|
Just popping in
|
@all A lot of information, which I currently cannot sort in. @Hans @joerg I'm using the Pegasos 2 emulation with bboot. I'm added the virtio devices as following to the working qemu call:
-device virtio-mouse-pci -device virtio-net-pci-non-transitional
I had the thought that qemu knows that "-m pegasos2" is 32bit, thus the virto devices will be 32bit too? So what do I have to tinker to get them mapped correctly? What kind of boot script?
|
|
|
|
Re: PCI device memory from BAR under qemu alwys zero
|
Posted on: 2023/9/12 13:56
#23
|
Just popping in
|
@geennaam I hope that the virtio-xx-pci devices are correctly emulated At least all vendor specific capabilities etc I find, and can read. These have the following structure:
struct virtio_pci_cap
{
u8 cap_vndr; /* Generic PCI field: PCI_CAP_ID_VNDR */
u8 cap_next; /* Generic PCI field: next ptr. */
u8 cap_len; /* Generic PCI field: capability length */
u8 cfg_type; /* Identifies the structure. See VIRTIO_PCI_CAP_XXX below */
u8 bar; /* Where to find it. */
u8 id; /* Multiple capabilities of the same type */
u8 padding[2]; /* Pad to full dword. */
le32 bar_offset; /* Offset within bar. */
le32 bar_length; /* Length of the structure, in bytes. */
};
And all values I retrieve for them looks correct (and even don't consist only out of zeros)
Reading pci device capabilities
Found capability 0x09 at offset 132:
cap_vndr = 9
cap_next = 112
cap_len = 20
cfg_type = 5
bar = 0
offset = 0
length = 0
Found capability 0x09 at offset 112:
cap_vndr = 9
cap_next = 96
cap_len = 20
cfg_type = 2
bar = 4
offset = 12288
length = 4096
Found capability 0x09 at offset 96:
cap_vndr = 9
cap_next = 80
cap_len = 16
cfg_type = 4
bar = 4
offset = 8192
length = 4096
Found capability 0x09 at offset 80:
cap_vndr = 9
cap_next = 64
cap_len = 16
cfg_type = 3
bar = 4
offset = 4096
length = 4096
Found capability 0x09 at offset 64:
cap_vndr = 9
cap_next = 0
cap_len = 16
cfg_type = 1
bar = 4
offset = 0
length = 4096
Just that the bar memory is zeroed on qemu.
|
|
|
|
Re: PCI device memory from BAR under qemu alwys zero
|
Posted on: 2023/9/12 12:50
#24
|
Just popping in
|
@geennaam
Even using BaseAddress doesn't result in other values but zeros. But I think my problem is that i running under qemu.
Dumping memory on a real X5020 dumps even values other than zero.
BTW in which case you have to use the physical instead of the base address? (Even that they are most of time the same?)
|
|
|
|
PCI device memory from BAR under qemu alwys zero
|
Posted on: 2023/9/12 10:33
#25
|
Just popping in
|
Does anyone know how to read out the memory of an PIC device defined via a BAR? I find my PCI device and call on that the GetResourceRange, and dumps the memory like this:
struct PCIResourceRange *resourceRange = pciDevice->GetResourceRange( 4 );
if( resourceRange == NULL ) {
printf( "BAR number %u returned no valid resource range.\n",4 );
goto exit_lockPCIDevice;
}
void *p = (void*)(resourceRange->Physical);
display_mem( p,resourceRange->Size,32 );
pciDevice->FreeResourceRange( resourceRange );
exit_lockPCIDevice:
But regardless which PCI device and matching bar I choose. I always only read zeros. And at least for some device I know there must be some values presents. What am I missing?
Edited by MigthyMax on 2023/9/12 12:51:15
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/9/12 8:52
#26
|
Just popping in
|
@joerg Quote: I'm not 100% sure, but I don't think elf.library works that way. Instead of using traps which resolve it on first access it loads all .so used by the executable and resolves everything before _start() in the executable is called.
That's the other variant. Same, same but different, just takes longer during startup, because no lazy resolving. @Futaura Quote: Quote: Program header loadable segments are now loaded as segment even if they are executable. This caused some problems with older binaries that have .text and .rodata in the same segment; if the loader detects such a segment, it is ignored and the sections are loaded separately. This behaviour is required because the PLT must be correctly placed relative to the text segment.
So instead of using the program headers (segments) to allocated memory as described by the elf file, the elf.library allocates memory by sections? I thought that this is one of the smart ideas of the elf file format, that a linker just allocates memory as describes and than populate it from the content, resp. fills its as described by the ABI. And you say, that is because of the support of M68k stubs stuff? Quote: Quote: Changed the initial .ctors/.dtors sentinel entries from NULL to 0xffffffff to conform with the ELF standard.
This makes the ctors/dtors crash (as elf.library tries to execute address 0xfffffffc instead of skipping this entry), when I try to recompile your test code here.
Mhh, that could be case why stuff crashes with new binutils. But i read further down that this is already fixed in new elf.library. And that ctor/dtor stuff heavily even depends on the used c library. @kas1e Quote: Probably all clear now, to sort it out we need:
1). Make new binutils to have .rodata as independent and marked as R 2). Check after, if elf.library prior 53.37, if this .so test case passes and didn't crashes. If it still, then another bug to fix 3). Check after, if ctor/dtor and ctor2/dtor2 prinfs fine with test case. be it newlib or clib2
After all done, we can go checking how make working .init_array / .fini_array. As i see in changelog for elf.library, alfkil add support of it, but it's untested.
Ok, so for binutils elft to be realized is point 1, to have new binutils to behave like old ones. Maybe the 333 isn't absolut correct, will investigate on it.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/9/8 7:09
#27
|
Just popping in
|
@Futaura Quote: I don't think they should be 0 - they need to point to the location of the respective function in .text (at least, that's the case in libc.so).
I'm neither an expert, but the value depends on where the function is. If the function is outside the own sobj the value should be zero. (I don't fin the reference anymore) As long i remember the zero indicates to the dynamic linker -> you have to do stuff to find the address of my desired method. A none zero value can directly be used to calculate the address in .text section. But the method must be present in the sobj file. Probably there are more things to consider if going more in detail, but that should be the general path. An elf.library with more debug out can always help. But maybe you can look at the elf source, and tell how the PLT table is build by the elf.library for sobjs files.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/9/7 12:19
#28
|
Just popping in
|
@Futaura Quote: I might be wrong, but it looks like the puts@plt jump is not targeted at a PLT entry. I read/objdupo/readelf a lot too, and comes to nearly the same conclusion that the PLT entry seems to be wrong. The PLT is build by the dynamic linker (elf.library). Reading the ABI the implementation is specific for each OS target. But the lazy variant is to setup traps methods, which gets called resolves the desired address of the function, patches the PLT and/or the calling code (I didn't understand that completely), so that the next call doesn't need to be trapped, but just execute the desired method. So long for the theory. Disassemble the code and sections etc from the build with the old binutils to the new binutils, i only found differences which I think of might have an impact. The .rodata section has no standalone read only segment: Segment/Section old binutils look like this: Quote: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x10000000 0x10000000 0x00688 0x01060 R E 0x10000 LOAD 0x002000 0x10002000 0x10002000 0x00034 0x00034 R 0x10000 LOAD 0x002034 0x10012034 0x10012034 0x000f8 0x000f8 RW 0x10000 DYNAMIC 0x002074 0x10012074 0x10012074 0x000a8 0x000a8 RW 0x4
Section to Segment mapping: Segment Sections... 00 .hash .dynsym .dynstr .rela.dyn .rela.got2 .rela.plt .text .plt 01 .rodata 02 .ctors .dtors .got2 .dynamic .data .got 03 .dynamic
The new binutils: Quote: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x10000000 0x10000000 0x02034 0x02034 R E 0x10000 LOAD 0x002034 0x10012034 0x10012034 0x000f8 0x000f8 RW 0x10000 DYNAMIC 0x002074 0x10012074 0x10012074 0x000a8 0x000a8 RW 0x4
Section to Segment mapping: Segment Sections... 00 .hash .dynsym .dynstr .rela.dyn .rela.got2 .rela.plt .text .plt .rodata 01 .ctors .dtors .got2 .dynamic .data .got 02 .dynamic
The address and size differs too, but that is just owed to being a newer binutils version. And because .rodata (The read only data section) only contains static data, I don't see how this should affect the PLT stuff. As you too mention, you do not see any reference fo that too. But modifying the new binutils to let the .rodata section being writable, triggers something in the elf.library that the PLT function call works again. But another side effect is that ctor/dtor call "chaining" is broken. So i focused to see what else changes if in the new binutils rodata section is set to writeable, the segments/section look like this: Quote: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x010000 0x10000000 0x10000000 0x011b8 0x011b8 R E 0x10000 LOAD 0x012000 0x10012000 0x10012000 0x001d8 0x001d8 R 0x10000 LOAD 0x0121d8 0x100221d8 0x100221d8 0x000f0 0x000f0 RW 0x10000 DYNAMIC 0x012200 0x10022200 0x10022200 0x000b8 0x000b8 RW 0x4
Section to Segment mapping: Segment Sections... 00 .plt .text 01 .hash .dynsym .dynstr .rela.dyn .rela.got2 .rela.plt .rodata 02 .init_array .fini_array .got2 .dynamic .got 03 .dynamic
This variant i Think works without a crash, but doesn't have any .text.rela section: Quote: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .plt NOBITS 10000000 010000 000060 00 AX 0 0 4 [ 2] .text PROGBITS 10001000 011000 0001b8 00 AX 0 0 4 [ 3] .hash HASH 10012000 012000 00003c 04 A 4 0 4 [ 4] .dynsym DYNSYM 1001203c 01203c 0000a0 10 A 5 2 4 [ 5] .dynstr STRTAB 100120dc 0120dc 000038 00 A 0 0 1 [ 6] .rela.dyn RELA 10012114 012114 000030 0c A 4 0 4 [ 7] .rela.got2 RELA 10012144 012144 000048 0c AI 4 13 4 [ 8] .rela.plt RELA 1001218c 01218c 000018 0c AI 4 1 4 [ 9] .rodata PROGBITS 100121a4 0121a4 000031 00 A 0 0 4 [10] .eh_frame PROGBITS 100121d8 0121d8 000000 00 A 0 0 4 [11] .init_array INIT_ARRAY 100221d8 0121d8 000008 04 WA 0 0 4 [12] .fini_array FINI_ARRAY 100221e0 0121e0 000008 04 WA 0 0 4 [13] .got2 PROGBITS 100221e8 0121e8 000018 00 WA 0 0 4 [14] .dynamic DYNAMIC 10022200 012200 0000b8 08 WA 5 0 4 [15] .got PROGBITS 100222b8 0122b8 000010 04 WA 0 0 4 [16] .comment PROGBITS 00000000 0122c8 000023 01 MS 0 0 1 [17] .symtab SYMTAB 00000000 0122ec 000220 10 18 26 4 [18] .strtab STRTAB 00000000 01250c 000094 00 0 0 1 [19] .shstrtab STRTAB 00000000 0125a0 000097 00 0 0 1
Which doesn't make any sense for me to skip that section. But thus the relocation R_PPC_PLTREL24 is missing from the sobj file. So at least this verifies that this relocation is ignored by the elf.library, or better elf.library doesn't care that this is missing. Anyway without insight what the elf.library actually does for PLT, I think I'm stuck.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/8/30 10:38
#29
|
Just popping in
|
@kas1e
OK, maybe the cause is that the .rodata is even marked as Executable, and that causes the crash, and moving .rodata being writable has the side effect of getting rid of the E flag.
Thus the Writebale flag is not really needed. But it has the side effect of getting rid of the Executable flag. Which than don't led to an crash.
Best solution should be to have .rodata only flagged as Readable without any other flags. Which will results in that .rodata gets its own segment. Thus looking more like the old binutils.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/8/30 8:58
#30
|
Just popping in
|
@LiveForIt I don't think it is bugos source. The source can be found from Issue 139 from aba1/adtools. If the .rodata section is write protected, the executable fails with:
AmigaOne X5000 release
Machine model: 9 (AmigaOne X5000/20)
Dump of context at 0xEFD653E0
Trap type: Program exception
Current kernel stack pointer: 0x021697B0
Machine State (raw): 0x0002F030
Machine State (verbose): [Critical Ints on] [ExtInt on] [User] [IAT on] [DAT on]
Instruction pointer: 0x7FFC9CE0
Crashed process: test_dyn (0x6613C630)
Program exception verbose description:
Illegal instruction
Exception Syndrome Register: 0x08000000
0: E0A4D59C 60689C60 00000002 60706008 00000118 00000040 60A0E680 00000003
8: 60A0E68C 7FFC90F0 00000008 60689BD0 000007A8 61294CF8 60671578 00000001
16: 65FB99BC 608CC420 65D4D010 00000000 60689DA8 7FFC9004 0201DBF0 0201DBCC
24: 0201DB90 0201DB74 00000001 0201DBB0 613777B0 00000004 60A166A8 60689C60
CR: 59555335 XER: C000006F CTR: 7FFC90F0 LR: 7FFC9120
Temporary stack trace:
#0: 0x7FFC9CE0
#1: in module elf.library.kmod+0x00009898 (0x019879D8)
#2: in module newlib.library.kmod+0x00000228 (0x01A5E128)
#3: in module newlib.library.kmod+0x000025D8 (0x01A604D8)
#4: in module newlib.library.kmod+0x00003340 (0x01A61240)
#5: in module newlib.library.kmod+0x00003864 (0x01A61764)
#6: 0x7FA3628C
#7: in module dos.library.kmod+0x00029E18 (0x01959018)
#8: in module kernel+0x0005F280 (0x0185F280)
#9: in module kernel+0x0005F2F8 (0x0185F2F8)
#10: 0x00000000
msr: 0x00003032
TLB1 (64 entries):
* [ 50]: size=7 tid = 0 TS = 1 epn=0xFE000000 rpn=0x0000000F_FE000000 WIMG=0x5 XXWWRR=0xF protected
* [ 51]: size=6 tid = 0 TS = 1 epn=0x01000000 rpn=0x00000000_01000000 WIMG=0x0 XXWWRR=0x5 protected
* [ 52]: size=6 tid = 0 TS = 1 epn=0x01400000 rpn=0x00000000_01400000 WIMG=0x0 XXWWRR=0x5 protected
* [ 53]: size=6 tid = 0 TS = 1 epn=0x01800000 rpn=0x00000000_01800000 WIMG=0x0 XXWWRR=0x33 protected
* [ 54]: size=6 tid = 0 TS = 1 epn=0x01C00000 rpn=0x00000000_01C00000 WIMG=0x0 XXWWRR=0x33 protected
* [ 55]: size=5 tid = 0 TS = 1 epn=0x02000000 rpn=0x00000000_02000000 WIMG=0x0 XXWWRR=0xF protected
* [ 56]: size=5 tid = 0 TS = 1 epn=0x02100000 rpn=0x00000000_02100000 WIMG=0x0 XXWWRR=0xF protected
* [ 57]: size=5 tid = 0 TS = 1 epn=0x02200000 rpn=0x00000000_02200000 WIMG=0x0 XXWWRR=0xF protected
* [ 58]: size=4 tid = 0 TS = 1 epn=0x02300000 rpn=0x00000000_02300000 WIMG=0x0 XXWWRR=0xF protected
* [ 59]: size=4 tid = 0 TS = 1 epn=0x02340000 rpn=0x00000000_02340000 WIMG=0x0 XXWWRR=0xF protected
* [ 60]: size=3 tid = 0 TS = 1 epn=0x02380000 rpn=0x00000000_02380000 WIMG=0x0 XXWWRR=0xF protected
* [ 61]: size=7 tid = 0 TS = 0 epn=0xFE000000 rpn=0x0000000F_FE000000 WIMG=0x5 XXWWRR=0xF protected
* [ 62]: size=A tid = 0 TS = 0 epn=0x00000000 rpn=0x00000000_00000000 WIMG=0x0 XXWWRR=0x3F protected
* [ 63]: size=A tid = 0 TS = 0 epn=0x40000000 rpn=0x00000000_40000000 WIMG=0x0 XXWWRR=0x3F protected
HAL_MaxTLB = 49, HAL_NextTLB = 0
MMUCFG = 0x064809C4
mas0 = 0x103F0000
mas1 = 0xC0000A00
mas2 = 0x40000000
mas3 = 0x4000003F
mas4 = 0x00000100
mas5 = 0x00000000
mas6 = 0x00000001
mas7 = 0x00000000
mas8 = 0x00000000
Disassembly of crash site:
7FFC9CD0: 00000000 .word 0x00000000
7FFC9CD4: 00000000 .word 0x00000000
7FFC9CD8: 00000000 .word 0x00000000
7FFC9CDC: 00000000 .word 0x00000000
>7FFC9CE0: 00000000 .word 0x00000000
7FFC9CE4: 00000000 .word 0x00000000
7FFC9CE8: 00000000 .word 0x00000000
7FFC9CEC: 00000000 .word 0x00000000
7FFC9CF0: 00000000 .word 0x00000000
7FFC9CF4: 00000000 .word 0x00000000
Kernel command line: serial
Registers pointing to code:
r9 : Work:8/capehill/new_ld/libf.so:ctor()+0x0 (section 7 @ 0xEC)
r13: module LIBS:AmiSSL/amissl_v312.library at 0x61294CF8 (section 2 @ 0x1CD4)
r15: module test_dyn at 0x00000001 (section 0 @ 0xFFFFFFDC)
r21: Work:8/capehill/new_ld/libf.so:__shlib_call_constructors()+0x0 (section 7 @ 0x0)
r22: native kernel module elf.library.kmod+0x0069fab0
r23: native kernel module elf.library.kmod+0x0069fa8c
r24: native kernel module elf.library.kmod+0x0069fa50
r25: native kernel module elf.library.kmod+0x0069fa34
r26: module test_dyn at 0x00000001 (section 0 @ 0xFFFFFFDC)
r27: native kernel module elf.library.kmod+0x0069fa70
ip : unknown (0x7FFC9CE0)
lr : Work:8/capehill/new_ld/libf.so:ctor()+0x30 (section 7 @ 0x11C)
ctr: Work:8/capehill/new_ld/libf.so:ctor()+0x0 (section 7 @ 0xEC)
Stack trace:
(0x60689C60) 0x7FFC9CE0 [cannot decode symbol]
(0x60689C70) Work:8/capehill/new_ld/libf.so:ctor()+0x30 (section 7 @ 0x11C)
(0x60689CD0) native kernel module newlib.library.kmod+0x00000228
(0x60689D10) native kernel module newlib.library.kmod+0x000025d8
(0x60689D60) native kernel module newlib.library.kmod+0x00003340
(0x60689F10) native kernel module newlib.library.kmod+0x00003864
(0x60689F40) test_dyn:_start()+0x1e0 (section 7 @ 0x3288)
(0x60689F90) native kernel module dos.library.kmod+0x00029e18
(0x60689FC0) native kernel module kernel+0x0005f280
(0x60689FD0) native kernel module kernel+0x0005f2f8
Disassembly of crash site:
7FFC9CD0: 00000000 .word 0x00000000
7FFC9CD4: 00000000 .word 0x00000000
7FFC9CD8: 00000000 .word 0x00000000
7FFC9CDC: 00000000 .word 0x00000000
>7FFC9CE0: 00000000 .word 0x00000000
7FFC9CE4: 00000000 .word 0x00000000
7FFC9CE8: 00000000 .word 0x00000000
7FFC9CEC: 00000000 .word 0x00000000
7FFC9CF0: 00000000 .word 0x00000000
7FFC9CF4: 00000000 .word 0x00000000
Stack pointer (0x60689C60) is inside bounds
Redzone is OK (4)
68k register dump
DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Ready Tasks
WinFrame 1 Process (pri 5, sigrec 0x00800000, sigwait 0xFF800000, masked 0x00800000)
compose.task (pri 1, sigrec 0x00000020, sigwait 0x00000021, masked 0x00000020)
Workbench (pri 1, sigrec 0x80000100, sigwait 0x80000000, masked 0x80000000)
AmiDock (pri 0, sigrec 0x00300100, sigwait 0x00000100, masked 0x00000100)
NotificationServer (pri 0, sigrec 0x08000000, sigwait 0xF8001000, masked 0x08000000)
TCP/IP Control (pri 0, sigrec 0x40000100, sigwait 0xF8009080, masked 0x40000000)
ELF Collector (pri -5, sigrec 0x00000100, sigwait 0x00000100, masked 0x00000100)
CPUDock_idleTask (pri -127, sigrec 0x00000000, sigwait 0x40000000, masked 0x00000000)
idle.task (pri -128, sigrec 0x00000000, sigwait 0x00000000, masked 0x00000000)
Waiting Tasks
DH2/SmartFilesystem 1.293 (pri 10, sigrec 0x00000000, sigwait 0xE0000100, masked 0x00000000)
p50x0sata.device Port 0 (pri 12, sigrec 0x10000000, sigwait 0xC0007000, masked 0x00000000)
appdir envarc manager (pri -50, sigrec 0x00000000, sigwait 0x00000100, masked 0x00000000)
dos_signal_server (pri -5, sigrec 0x00000000, sigwait 0x00000100, masked 0x00000000)
gfx FSL DMA handler (pri 0, sigrec 0x00000000, sigwait 0x80000000, masked 0x00000000)
dopus_clock (pri 1, sigrec 0x00000000, sigwait 0xC0000000, masked 0x00000000)
DMA1 Channel 4 Handler (pri 0, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
hub.usbfd (pri 0, sigrec 0x00000000, sigwait 0x30000000, masked 0x00000000)
hub.usbfd (pri 0, sigrec 0x80000000, sigwait 0x30000000, masked 0x00000000)
EHCI Controller Task Unit 1 (pri 15, sigrec 0x00000000, sigwait 0xBE009000, masked 0x00000000)
USB stack (pri 18, sigrec 0x00000000, sigwait 0xFC00D000, masked 0x00000000)
EHCI Controller Task Unit 0 (pri 15, sigrec 0x00000000, sigwait 0xBE009000, masked 0x00000000)
vsata disk changer (pri 0, sigrec 0x00000000, sigwait 0x80000000, masked 0x00000000)
ScreenBlanker Library. (pri 1, sigrec 0x00000100, sigwait 0xE8001000, masked 0x00000000)
CON/con-handler 53.82 (pri 5, sigrec 0x00000000, sigwait 0xB8000100, masked 0x00000000)
DH3/SmartFilesystem 1.293 (pri 10, sigrec 0x00000000, sigwait 0xE0000100, masked 0x00000000)
hid.usbfd (pri 10, sigrec 0x00000100, sigwait 0xE0000000, masked 0x00000000)
HID Keyboard (pri 10, sigrec 0x00000000, sigwait 0x90001000, masked 0x00000000)
serial.device (pri 1, sigrec 0x00000000, sigwait 0x7E000000, masked 0x00000000)
DMA2 Channel 3 Handler (pri 0, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
DMA1 Channel 3 Handler (pri 0, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
DMA2 Channel 2 Handler (pri 0, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
DMA1 Channel 2 Handler (pri 0, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
DMA2 Channel 1 Handler (pri 0, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
DMA1 Channel 1 Handler (pri 0, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
DMA2 Channel 4 Handler (pri 0, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
dos_filedir_notify (pri 5, sigrec 0x80000000, sigwait 0x40001000, masked 0x00000000)
ICD1/CDFileSystem 53.11 (pri 10, sigrec 0x00000000, sigwait 0x00000100, masked 0x00000000)
ICD0/CDFileSystem 53.11 (pri 10, sigrec 0x00000000, sigwait 0x00000100, masked 0x00000000)
DH2/SmartFilesystem 1.293 (pri 11, sigrec 0x00000000, sigwait 0x00000100, masked 0x00000000)
DH3/SmartFilesystem 1.293 (pri 11, sigrec 0x00000000, sigwait 0x00000100, masked 0x00000000)
URL/launch-handler 53.39 (pri 5, sigrec 0x00000100, sigwait 0x80000000, masked 0x00000000)
TEXTCLIP/textclip-handler 53.4 (pri 3, sigrec 0x00000100, sigwait 0x80000000, masked 0x00000000)
RANDOM/Random-Handler 52.1 (pri 5, sigrec 0x00000000, sigwait 0x00000100, masked 0x00000000)
P50x0 Ethernet (pri 20, sigrec 0x00000000, sigwait 0x00001000, masked 0x00000000)
RexxMaster (pri 4, sigrec 0x00000100, sigwait 0xC0000000, masked 0x00000000)
rx_gc (pri 100, sigrec 0x00000000, sigwait 0x80000001, masked 0x00000000)
application.library messageserver (pri 0, sigrec 0x00000000, sigwait 0xC0000000, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x80000010, masked 0x00000000)
Background CLI (pri 0, sigrec 0x00000100, sigwait 0x14001080, masked 0x00000000)
X-Dock (pri 0, sigrec 0x01000100, sigwait 0xFE001000, masked 0x00000000)
hid.usbfd (pri 10, sigrec 0x00000100, sigwait 0xE0000000, masked 0x00000000)
HID Mouse (pri 10, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
ramlib.support (pri -2, sigrec 0x00000000, sigwait 0x80005000, masked 0x00000000)
New Process (pri 0, sigrec 0x80000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
New Process (pri 0, sigrec 0x00000000, sigwait 0x00000010, masked 0x00000000)
ramlib (pri 1, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
ContextMenus (pri 0, sigrec 0x00000000, sigwait 0xE0001000, masked 0x00000000)
KeymapSwitcher.docky (pri 0, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
TCP/IP Configuration (pri 0, sigrec 0x00000100, sigwait 0xF8003000, masked 0x00000000)
ContextMenus Command Dispatcher (pri 1, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
Mounter Task (pri -1, sigrec 0x00000000, sigwait 0xB0001000, masked 0x00000000)
Mounter GUI (pri 0, sigrec 0x00000000, sigwait 0x80007000, masked 0x00000000)
Mounter Companion Process (pri -1, sigrec 0x00000000, sigwait 0x80003000, masked 0x00000000)
Workbench DosList Notify (pri 1, sigrec 0x00000100, sigwait 0x00003000, masked 0x00000000)
AsyncWB (pri 0, sigrec 0x00000100, sigwait 0xC0001000, masked 0x00000000)
CDDAPatch (pri 0, sigrec 0x00000100, sigwait 0x80001000, masked 0x00000000)
CON/con-handler 53.82 (pri 5, sigrec 0x00000000, sigwait 0xA0000100, masked 0x00000000)
CON/con-handler 53.82 (pri 5, sigrec 0x00000000, sigwait 0xA0000100, masked 0x00000000)
RAWBInfo (pri 0, sigrec 0x00000100, sigwait 0x80001000, masked 0x00000000)
FKey (pri 0, sigrec 0x00000100, sigwait 0xC000D000, masked 0x00000000)
CON/con-handler 53.82 (pri 5, sigrec 0x00000000, sigwait 0xA0000100, masked 0x00000000)
ClickToFront (pri 21, sigrec 0x00000100, sigwait 0xE000D000, masked 0x00000000)
DefIcons (pri 0, sigrec 0x00000100, sigwait 0x80009000, masked 0x00000000)
CON/con-handler 53.82 (pri 5, sigrec 0x00000000, sigwait 0xA0000100, masked 0x00000000)
CON/con-handler 53.82 (pri 5, sigrec 0x00000000, sigwait 0xA0000100, masked 0x00000000)
Background CLI (pri 0, sigrec 0x00000100, sigwait 0x54009000, masked 0x00000000)
Workbench Clipboard Server (pri 1, sigrec 0x00000100, sigwait 0x80000000, masked 0x00000000)
TCP/IP Superserver (pri 0, sigrec 0x00000100, sigwait 0xD0000080, masked 0x00000000)
TCP/IP Log (pri 0, sigrec 0x00000000, sigwait 0x80003000, masked 0x00000000)
▒ IPrefs ▒ (pri 0, sigrec 0x00000000, sigwait 0x0000F000, masked 0x00000000)
dopus_arbiter (pri 0, sigrec 0x00000000, sigwait 0x00000100, masked 0x00000000)
dopus_hotkeez (pri 1, sigrec 0x00000000, sigwait 0xC0000000, masked 0x00000000)
texteditor.gadget Clipboard Server (pri 1, sigrec 0x00000100, sigwait 0x80000000, masked 0x00000000)
select.gadget prefs (pri 0, sigrec 0x00000100, sigwait 0x80001000, masked 0x00000000)
hid.usbfd (pri 10, sigrec 0x00000100, sigwait 0xE0000000, masked 0x00000000)
ConClip (pri 0, sigrec 0x00000000, sigwait 0x80000000, masked 0x00000000)
HID Consumer (pri 10, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
HID Consumer (pri 10, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
diskimage.device unit 1 (pri 4, sigrec 0x00000100, sigwait 0xC0000000, masked 0x00000000)
diskimage.device unit 0 (pri 4, sigrec 0x00000100, sigwait 0xC0000000, masked 0x00000000)
diskimage.device unit 5 (pri 4, sigrec 0x00000100, sigwait 0xC0000000, masked 0x00000000)
diskimage.device unit 4 (pri 4, sigrec 0x00000100, sigwait 0xC0000000, masked 0x00000000)
HID Keyboard (pri 10, sigrec 0x00000000, sigwait 0x90001000, masked 0x00000000)
HID Keyboard (pri 10, sigrec 0x00000000, sigwait 0x90001000, masked 0x00000000)
HID Keyboard (pri 10, sigrec 0x00000000, sigwait 0x90001000, masked 0x00000000)
HID Keyboard (pri 10, sigrec 0x00000000, sigwait 0x90001000, masked 0x00000000)
hid.usbfd (pri 10, sigrec 0x00000100, sigwait 0xE0000000, masked 0x00000000)
HID Joystick (pri 10, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
hid.usbfd (pri 10, sigrec 0x00000100, sigwait 0xE0000000, masked 0x00000000)
hid.usbfd (pri 10, sigrec 0x00000100, sigwait 0xE0000000, masked 0x00000000)
hid.usbfd (pri 10, sigrec 0x00000100, sigwait 0xE0000000, masked 0x00000000)
hid.usbfd (pri 10, sigrec 0x00000100, sigwait 0xE0000000, masked 0x00000000)
hid.usbfd (pri 10, sigrec 0x00000100, sigwait 0xE0000000, masked 0x00000000)
hid.usbfd (pri 10, sigrec 0x00000100, sigwait 0xE0000000, masked 0x00000000)
HID Mouse (pri 10, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
HID Consumer (pri 10, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
HID Mouse (pri 10, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
AUDIO/AHI-Handler 6.2 (pri 5, sigrec 0x00000000, sigwait 0x00000100, masked 0x00000000)
APPDIR/appdir-handler 54.21 (pri 5, sigrec 0x00000100, sigwait 0x80000000, masked 0x00000000)
USB stack Process (pri 0, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
MassStorage Notifier (pri 0, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
DST watcher (pri 0, sigrec 0x00000000, sigwait 0xC0000000, masked 0x00000000)
NotifyA Server (pri 1, sigrec 0x00000000, sigwait 0xE8001000, masked 0x00000000)
string.gadget server (pri 1, sigrec 0x00000100, sigwait 0x40000000, masked 0x00000000)
datatypes.library (pri 1, sigrec 0x00000000, sigwait 0x80001000, masked 0x00000000)
RAM/ram-handler 54.26 (pri 10, sigrec 0x00000100, sigwait 0x80000000, masked 0x00000000)
ENV/env-handler 54.19 (pri 5, sigrec 0x00000100, sigwait 0x80000000, masked 0x00000000)
CON/con-handler 53.82 (pri 5, sigrec 0x00000000, sigwait 0xA0000100, masked 0x00000000)
RAW/con-handler 53.82 (pri 5, sigrec 0x00000000, sigwait 0xA0000100, masked 0x00000000)
CON/con-handler 53.82 (pri 5, sigrec 0x00000000, sigwait 0xA0000100, masked 0x00000000)
SFS DosList handler (pri 19, sigrec 0x00000000, sigwait 0x80000000, masked 0x00000000)
dos_nbmd_process (pri 5, sigrec 0x00000000, sigwait 0x00001100, masked 0x00000000)
dos_lock_handler (pri 5, sigrec 0x00000000, sigwait 0x00001100, masked 0x00000000)
hub.usbfd (pri 0, sigrec 0x00000000, sigwait 0x30000000, masked 0x00000000)
hub.usbfd (pri 0, sigrec 0x00000000, sigwait 0x30000000, masked 0x00000000)
hub.usbfd (pri 0, sigrec 0x00000000, sigwait 0x30000000, masked 0x00000000)
hub.usbfd (pri 0, sigrec 0x00000000, sigwait 0x30000000, masked 0x00000000)
p50x0sata.device Port 1 (pri 12, sigrec 0x00000000, sigwait 0xC0007000, masked 0x00000000)
Exec Command and Control (pri 30, sigrec 0x00000000, sigwait 0x80000000, masked 0x00000000)
Suspended Tasks
Somether you see it fails at
(0x60689C70) Work:8/capehill/new_ld/libf.so:ctor()+0x30 (section 7 @ 0x11C)
And if disaamble the method, there is nothing uncommon:
ppc-amigaos-objdump -d libf.so --disassemble=ctor
libf.so: file format elf32-powerpc-amigaos
Disassembly of section .text:
10000460 <ctor>:
10000460: 94 21 ff f0 stwu r1,-16(r1)
10000464: 7c 08 02 a6 mflr r0
10000468: 90 01 00 14 stw r0,20(r1)
1000046c: 93 c1 00 08 stw r30,8(r1)
10000470: 93 e1 00 0c stw r31,12(r1)
10000474: 7c 3f 0b 78 mr r31,r1
10000478: 42 9f 00 05 bcl 20,4*cr7+so,1000047c <ctor+0x1c>
1000047c: 7f c8 02 a6 mflr r30
10000480: 80 1e ff e0 lwz r0,-32(r30)
10000484: 7f c0 f2 14 add r30,r0,r30
10000488: 80 7e 80 00 lwz r3,-32768(r30)
1000048c: 48 00 0b c5 bl 10001050 <puts@plt>
10000490: 60 00 00 00 nop
10000494: 39 7f 00 10 addi r11,r31,16
10000498: 80 0b 00 04 lwz r0,4(r11)
1000049c: 7c 08 03 a6 mtlr r0
100004a0: 83 cb ff f8 lwz r30,-8(r11)
100004a4: 83 eb ff fc lwz r31,-4(r11)
100004a8: 7d 61 5b 78 mr r1,r11
100004ac: 4e 80 00 20 blr
Than there is relecation in the .rela.plt section
10001050 00000415 R_PPC_JMP_SLOT 00000000 puts + 0
But nothing that indicates that data from .rodata section is target. So i think that the current elf.library makes something which want to modify data in the .rodata section or the associated segemnt with it.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/8/21 8:00
#31
|
Just popping in
|
@rwo
and to add to as1e answer, you should probably even use the clib from afxgroup. Because if a c library can handle fini_/init_array than that one.
And you even need the up to now un released elf.library from eflpipe.
In this three constellation binutils/c lib/elf.libray there might still be some issued regarding that. But we are trying to figure that out.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/8/18 21:20
#32
|
Just popping in
|
@joerg
Is it just that relic which can be removed. And if so why? Or how to determine if relics are unneeded?
|
|
|
|
Re: have you seen this?
|
Posted on: 2023/8/14 15:28
#33
|
Just popping in
|
@kas1e
Cannot find Amiga WipeOut version to buy. That is one reason to port it.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/8/13 18:57
#34
|
Just popping in
|
@joerg
Do you know why the __amigaos4__ and __SDA_BASE__ needs to kept? The __start__ is is clear to be kept, because it defines the entry point of the executable.
|
|
|
|
Re: can anybody explain about current situation with BREL Relocations ?
|
Posted on: 2023/8/12 8:40
#35
|
Just popping in
|
@joerg
You are really a great source of information! And every answer from you makes the picture bigger and clearer.
But to support baserel again in newer binutils and co will be the last point to improve, because that's really a AmigaOS specialty.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2023/8/11 8:59
#36
|
Just popping in
|
@joerg Quote: .text must not be writable. If elf.library ignores it for code it may not be a problem, but if it doesn't and allocates the code in writable memory it's a problem. Quote: Read-only (.text, .rodata, ...) and writable (.sbss) sections mustn't be in the same segment. Executable (.text) and non-executable (everything else) sections mustn't be in the same segment either. Both shouldn't be a problem to be fixed. Could you open a or two issues on the github project.
|
|
|
|
Re: can anybody explain about current situation with BREL Relocations ?
|
Posted on: 2023/8/11 8:54
#37
|
Just popping in
|
@joerg Quote: But the most use case is loading executables resident, which can be done on AmigaOS with the C:Resident command, or by setting the p(ure) (=re-entrant) and h(old) (=keep in memory) protection bits. For example for shell commands used often that's much faster since it only has to be loaded once from disk (and code and rodata relocation done only once by elf.library) and isn't unloaded after it exits. The next time it's simply started from memory, and it can be executed multiple times by different shells at the same time. Of course that can only work if every task/shell running it has an own copy of the .data/.bss, only .text (code) and .rodata (read-only data) are shared. Even if it's not executed by different tasks at the same time the copy of .bss/.data is required since the program may modify global variables in .bss/.data but only works if they are set to the initial values at program start. Now things start to clear up for me. Now makes all sense. BTW, If i understand it correctly it is a nice feature of AmiagOS, that i can make executrices resident (aka cache them in memory) and thus speed up the execution, and if it calls multipel times at "once" reduce memory usage. I wasn't aware of that! @Futaura & Co I think that binutils (old and new in progress) have all things in place to support baserel. But gcc needs update to in regards to this feature. Anyway, it seems that gcc 2.x.y still supported baserel out of the box. So it seems that other targets even used to use or could use baserel. Does anyone know why it was drop out of gcc development? If we switch the viewpoint more to gcc and code generating: For me baserel and small data model is more er less the same concept except different used register. BUT i see that baserel does suffer from the ~65K size limitation. How is that achieved? @kas1e So to test the new binutils support for baserel, we need a setup of gcc 4.0.4 and new binutils.
|
|
|
|
Re: can anybody explain about current situation with BREL Relocations ?
|
Posted on: 2023/8/10 15:02
#38
|
Just popping in
|
@joerg Quote: -mbaserel uses a special C library startup in the baserel directory which creates a copy of the data and bss and uses that for the current instance instead of the data and bss in the executable, making it possible to run multiple instances using the same code but different data at the same time. -msmall-data uses the same crtbegin.o as not using -msmall-data which doesn't create a copy of the sdata/sbss. IIRC the r13 based -msmall-data model has some size limit on data and bss, which the r2 based -mbaserel doesn't have. Ok, so -baserel is more in direction to how TLS works on other OSes. Each instance get its own data and bss section. Probably only the bss section, because the data section contains the program code, which should be re-entrant, so can be shared? What do you mean with instance? I don't get it how it works/worked. An executable gets loaded by the elf library, and the elf.library set ups the initial task for the executable. The initial task executes the special C library startup code and setup the baserel stuff. If the executable gets started a second time. Nothing is shared from the first run, hence two complete disjoint setup even being the same program. The only setup I can come to mind is a amiga library. Which gets executed by multiple task simultaneously, and each task would have its own parameter/variable memory block. But that must be somehow setup by the library during opening. So for me it still more or less the same, except the used register, and maybe the baserel has no size limitation. But I'm not sure about that. Maybe I should look into the AmiSSL ticket to get some more insight.
|
|
|
|
Re: can anybody explain about current situation with BREL Relocations ?
|
Posted on: 2023/8/9 18:08
#39
|
Just popping in
|
@all
Wouldn't it not even be possible to use the sbss data model to achieve the same result (aka useful for re-entrant executables)?
|
|
|
|
Re: can anybody explain about current situation with BREL Relocations ?
|
Posted on: 2023/8/9 8:17
#40
|
Just popping in
|
@joerg
I thought the gcc -mbaserel option was (for amiga is) just a relative addressing mode. Similar to the .sbss in the ABI but using r2 as base pointer. And for .sbss and -baserel, that the common PPC relocations from the ABI are sufficient. But it seems the -mbaserel gcc option on the amiga gcc does even use the PPC OS4 BREL specific relocations?
Joerg do have a simple c example which result in emitted BREL relocations ?
|
|
|
|