Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
88 user(s) are online (51 user(s) are browsing Forums)

Members: 0
Guests: 88

more...

Headlines

Forum Index


Board index » All Posts (MigthyMax)




Re: PCI device memory from BAR under qemu alwys zero
Just popping in
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)

Go to top


Re: PCI device memory from BAR under qemu alwys zero
Just popping in
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?

Go to top


Re: PCI device memory from BAR under qemu alwys zero
Just popping in
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 
     cap_next 
112 
     cap_len 
20 
     cfg_type 

     bar 

     offset 

     length 

Found capability 0x09 at offset 112
:
     
cap_vndr 
     cap_next 
96 
     cap_len 
20 
     cfg_type 

     bar 

     offset 
12288 
     length 
4096 
Found capability 0x09 at offset 96
:
     
cap_vndr 
     cap_next 
80 
     cap_len 
16 
     cfg_type 

     bar 

     offset 
8192 
     length 
4096 
Found capability 0x09 at offset 80
:
     
cap_vndr 
     cap_next 
64 
     cap_len 
16 
     cfg_type 

     bar 

     offset 
4096 
     length 
4096 
Found capability 0x09 at offset 64
:
     
cap_vndr 
     cap_next 

     cap_len 
16 
     cfg_type 

     bar 

     offset 

     length 
4096


Just that the bar memory is zeroed on qemu.

Go to top


Re: PCI device memory from BAR under qemu alwys zero
Just popping in
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?)

Go to top


PCI device memory from BAR under qemu alwys zero
Just popping in
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);
  if( 
resourceRange == NULL ) {
    
printf"BAR number %u returned no valid resource range.\n",);

    goto 
exit_lockPCIDevice;
  }

  
void *= (void*)(resourceRange->Physical);

  
display_memp,resourceRange->Size,32 );

  
pciDevice->FreeResourceRangeresourceRange );

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
Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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
(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 pointer0x7FFC9CE0
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   XERC000006F  CTR7FFC90F0  LR7FFC9120
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

msr0x00003032
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 49HAL_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
:
 
7FFC9CD000000000   .word             0x00000000
 7FFC9CD4
00000000   .word             0x00000000
 7FFC9CD8
00000000   .word             0x00000000
 7FFC9CDC
00000000   .word             0x00000000
>7FFC9CE000000000   .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)
r13module LIBS:AmiSSL/amissl_v312.library at 0x61294CF8 (section 2 0x1CD4)
r15module test_dyn at 0x00000001 (section 0 0xFFFFFFDC)
r21Work:8/capehill/new_ld/libf.so:__shlib_call_constructors()+0x0 (section 7 0x0)
r22native 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)
r27native kernel module elf.library.kmod+0x0069fa70
ip 
unknown (0x7FFC9CE0)
lr Work:8/capehill/new_ld/libf.so:ctor()+0x30 (section 7 0x11C)
ctrWork:8/capehill/new_ld/libf.so:ctor()+0x0 (section 7 0xEC)

Stack trace:
(
0x60689C600x7FFC9CE0 [cannot decode symbol]
(
0x60689C70Work:8/capehill/new_ld/libf.so:ctor()+0x30 (section 7 0x11C)
(
0x60689CD0native kernel module newlib.library.kmod+0x00000228
(0x60689D10native kernel module newlib.library.kmod+0x000025d8
(0x60689D60native kernel module newlib.library.kmod+0x00003340
(0x60689F10native kernel module newlib.library.kmod+0x00003864
(0x60689F40test_dyn:_start()+0x1e0 (section 7 0x3288)
(
0x60689F90native kernel module dos.library.kmod+0x00029e18
(0x60689FC0native kernel module kernel+0x0005f280
(0x60689FD0native kernel module kernel+0x0005f2f8

Disassembly of crash site
:
 
7FFC9CD000000000   .word             0x00000000
 7FFC9CD4
00000000   .word             0x00000000
 7FFC9CD8
00000000   .word             0x00000000
 7FFC9CDC
00000000   .word             0x00000000
>7FFC9CE000000000   .word             0x00000000
 7FFC9CE4
00000000   .word             0x00000000
 7FFC9CE8
00000000   .word             0x00000000
 7FFC9CEC
00000000   .word             0x00000000
 7FFC9CF0
00000000   .word             0x00000000
 7FFC9CF4
00000000   .word             0x00000000
Stack pointer 
(0x60689C60is 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   5sigrec 0x00800000sigwait 0xFF800000masked 0x00800000)
                                 
compose.task (pri   1sigrec 0x00000020sigwait 0x00000021masked 0x00000020)
                                    
Workbench (pri   1sigrec 0x80000100sigwait 0x80000000masked 0x80000000)
                                      
AmiDock (pri   0sigrec 0x00300100sigwait 0x00000100masked 0x00000100)
                           
NotificationServer (pri   0sigrec 0x08000000sigwait 0xF8001000masked 0x08000000)
                               
TCP/IP Control (pri   0sigrec 0x40000100sigwait 0xF8009080masked 0x40000000)
                                
ELF Collector (pri  -5sigrec 0x00000100sigwait 0x00000100masked 0x00000100)
                             
CPUDock_idleTask (pri -127sigrec 0x00000000sigwait 0x40000000masked 0x00000000)
                                    
idle.task (pri -128sigrec 0x00000000sigwait 0x00000000masked 0x00000000)

Waiting Tasks
                   DH2
/SmartFilesystem 1.293  (pri  10sigrec 0x00000000sigwait 0xE0000100masked 0x00000000)
                      
p50x0sata.device Port 0 (pri  12sigrec 0x10000000sigwait 0xC0007000masked 0x00000000)
                        
appdir envarc manager (pri -50sigrec 0x00000000sigwait 0x00000100masked 0x00000000)
                            
dos_signal_server (pri  -5sigrec 0x00000000sigwait 0x00000100masked 0x00000000)
                          
gfx FSL DMA handler (pri   0sigrec 0x00000000sigwait 0x80000000masked 0x00000000)
                                  
dopus_clock (pri   1sigrec 0x00000000sigwait 0xC0000000masked 0x00000000)
                       
DMA1 Channel 4 Handler (pri   0sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                                    
hub.usbfd (pri   0sigrec 0x00000000sigwait 0x30000000masked 0x00000000)
                                    
hub.usbfd (pri   0sigrec 0x80000000sigwait 0x30000000masked 0x00000000)
                  
EHCI Controller Task Unit 1 (pri  15sigrec 0x00000000sigwait 0xBE009000masked 0x00000000)
                                    
USB stack (pri  18sigrec 0x00000000sigwait 0xFC00D000masked 0x00000000)
                  
EHCI Controller Task Unit 0 (pri  15sigrec 0x00000000sigwait 0xBE009000masked 0x00000000)
                           
vsata disk changer (pri   0sigrec 0x00000000sigwait 0x80000000masked 0x00000000)
                       
ScreenBlanker Library. (pri   1sigrec 0x00000100sigwait 0xE8001000masked 0x00000000)
                       
CON/con-handler 53.82  (pri   5sigrec 0x00000000sigwait 0xB8000100masked 0x00000000)
                   
DH3/SmartFilesystem 1.293  (pri  10sigrec 0x00000000sigwait 0xE0000100masked 0x00000000)
                                    
hid.usbfd (pri  10sigrec 0x00000100sigwait 0xE0000000masked 0x00000000)
                                 
HID Keyboard (pri  10sigrec 0x00000000sigwait 0x90001000masked 0x00000000)
                                
serial.device (pri   1sigrec 0x00000000sigwait 0x7E000000masked 0x00000000)
                       
DMA2 Channel 3 Handler (pri   0sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                       
DMA1 Channel 3 Handler (pri   0sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                       
DMA2 Channel 2 Handler (pri   0sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                       
DMA1 Channel 2 Handler (pri   0sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                       
DMA2 Channel 1 Handler (pri   0sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                       
DMA1 Channel 1 Handler (pri   0sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                       
DMA2 Channel 4 Handler (pri   0sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                           
dos_filedir_notify (pri   5sigrec 0x80000000sigwait 0x40001000masked 0x00000000)
                     
ICD1/CDFileSystem 53.11  (pri  10sigrec 0x00000000sigwait 0x00000100masked 0x00000000)
                     
ICD0/CDFileSystem 53.11  (pri  10sigrec 0x00000000sigwait 0x00000100masked 0x00000000)
                   
DH2/SmartFilesystem 1.293  (pri  11sigrec 0x00000000sigwait 0x00000100masked 0x00000000)
                   
DH3/SmartFilesystem 1.293  (pri  11sigrec 0x00000000sigwait 0x00000100masked 0x00000000)
                    
URL/launch-handler 53.39  (pri   5sigrec 0x00000100sigwait 0x80000000masked 0x00000000)
              
TEXTCLIP/textclip-handler 53.4  (pri   3sigrec 0x00000100sigwait 0x80000000masked 0x00000000)
                  
RANDOM/Random-Handler 52.1  (pri   5sigrec 0x00000000sigwait 0x00000100masked 0x00000000)
                               
P50x0 Ethernet (pri  20sigrec 0x00000000sigwait 0x00001000masked 0x00000000)
                                   
RexxMaster (pri   4sigrec 0x00000100sigwait 0xC0000000masked 0x00000000)
                                        
rx_gc (pri 100sigrec 0x00000000sigwait 0x80000001masked 0x00000000)
            
application.library messageserver (pri   0sigrec 0x00000000sigwait 0xC0000000masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x80000010masked 0x00000000)
                               
Background CLI (pri   0sigrec 0x00000100sigwait 0x14001080masked 0x00000000)
                                       
X-Dock (pri   0sigrec 0x01000100sigwait 0xFE001000masked 0x00000000)
                                    
hid.usbfd (pri  10sigrec 0x00000100sigwait 0xE0000000masked 0x00000000)
                                    
HID Mouse (pri  10sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                               
ramlib.support (pri  -2sigrec 0x00000000sigwait 0x80005000masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x80000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                  New 
Process (pri   0sigrec 0x00000000sigwait 0x00000010masked 0x00000000)
                                       
ramlib (pri   1sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                                 
ContextMenus (pri   0sigrec 0x00000000sigwait 0xE0001000masked 0x00000000)
                         
KeymapSwitcher.docky (pri   0sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                         
TCP/IP Configuration (pri   0sigrec 0x00000100sigwait 0xF8003000masked 0x00000000)
              
ContextMenus Command Dispatcher (pri   1sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                                 
Mounter Task (pri  -1sigrec 0x00000000sigwait 0xB0001000masked 0x00000000)
                                  
Mounter GUI (pri   0sigrec 0x00000000sigwait 0x80007000masked 0x00000000)
                    
Mounter Companion Process (pri  -1sigrec 0x00000000sigwait 0x80003000masked 0x00000000)
                     
Workbench DosList Notify (pri   1sigrec 0x00000100sigwait 0x00003000masked 0x00000000)
                                      
AsyncWB (pri   0sigrec 0x00000100sigwait 0xC0001000masked 0x00000000)
                                    
CDDAPatch (pri   0sigrec 0x00000100sigwait 0x80001000masked 0x00000000)
                       
CON/con-handler 53.82  (pri   5sigrec 0x00000000sigwait 0xA0000100masked 0x00000000)
                       
CON/con-handler 53.82  (pri   5sigrec 0x00000000sigwait 0xA0000100masked 0x00000000)
                                     
RAWBInfo (pri   0sigrec 0x00000100sigwait 0x80001000masked 0x00000000)
                                         
FKey (pri   0sigrec 0x00000100sigwait 0xC000D000masked 0x00000000)
                       
CON/con-handler 53.82  (pri   5sigrec 0x00000000sigwait 0xA0000100masked 0x00000000)
                                 
ClickToFront (pri  21sigrec 0x00000100sigwait 0xE000D000masked 0x00000000)
                                     
DefIcons (pri   0sigrec 0x00000100sigwait 0x80009000masked 0x00000000)
                       
CON/con-handler 53.82  (pri   5sigrec 0x00000000sigwait 0xA0000100masked 0x00000000)
                       
CON/con-handler 53.82  (pri   5sigrec 0x00000000sigwait 0xA0000100masked 0x00000000)
                               
Background CLI (pri   0sigrec 0x00000100sigwait 0x54009000masked 0x00000000)
                   
Workbench Clipboard Server (pri   1sigrec 0x00000100sigwait 0x80000000masked 0x00000000)
                           
TCP/IP Superserver (pri   0sigrec 0x00000100sigwait 0xD0000080masked 0x00000000)
                                   
TCP/IP Log (pri   0sigrec 0x00000000sigwait 0x80003000masked 0x00000000)
                                   
▒ IPrefs ▒ (pri   0sigrec 0x00000000sigwait 0x0000F000masked 0x00000000)
                                
dopus_arbiter (pri   0sigrec 0x00000000sigwait 0x00000100masked 0x00000000)
                                
dopus_hotkeez (pri   1sigrec 0x00000000sigwait 0xC0000000masked 0x00000000)
           
texteditor.gadget Clipboard Server (pri   1sigrec 0x00000100sigwait 0x80000000masked 0x00000000)
                          
select.gadget prefs (pri   0sigrec 0x00000100sigwait 0x80001000masked 0x00000000)
                                    
hid.usbfd (pri  10sigrec 0x00000100sigwait 0xE0000000masked 0x00000000)
                                      
ConClip (pri   0sigrec 0x00000000sigwait 0x80000000masked 0x00000000)
                                 
HID Consumer (pri  10sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                                 
HID Consumer (pri  10sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                      
diskimage.device unit 1 (pri   4sigrec 0x00000100sigwait 0xC0000000masked 0x00000000)
                      
diskimage.device unit 0 (pri   4sigrec 0x00000100sigwait 0xC0000000masked 0x00000000)
                      
diskimage.device unit 5 (pri   4sigrec 0x00000100sigwait 0xC0000000masked 0x00000000)
                      
diskimage.device unit 4 (pri   4sigrec 0x00000100sigwait 0xC0000000masked 0x00000000)
                                 
HID Keyboard (pri  10sigrec 0x00000000sigwait 0x90001000masked 0x00000000)
                                 
HID Keyboard (pri  10sigrec 0x00000000sigwait 0x90001000masked 0x00000000)
                                 
HID Keyboard (pri  10sigrec 0x00000000sigwait 0x90001000masked 0x00000000)
                                 
HID Keyboard (pri  10sigrec 0x00000000sigwait 0x90001000masked 0x00000000)
                                    
hid.usbfd (pri  10sigrec 0x00000100sigwait 0xE0000000masked 0x00000000)
                                 
HID Joystick (pri  10sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                                    
hid.usbfd (pri  10sigrec 0x00000100sigwait 0xE0000000masked 0x00000000)
                                    
hid.usbfd (pri  10sigrec 0x00000100sigwait 0xE0000000masked 0x00000000)
                                    
hid.usbfd (pri  10sigrec 0x00000100sigwait 0xE0000000masked 0x00000000)
                                    
hid.usbfd (pri  10sigrec 0x00000100sigwait 0xE0000000masked 0x00000000)
                                    
hid.usbfd (pri  10sigrec 0x00000100sigwait 0xE0000000masked 0x00000000)
                                    
hid.usbfd (pri  10sigrec 0x00000100sigwait 0xE0000000masked 0x00000000)
                                    
HID Mouse (pri  10sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                                 
HID Consumer (pri  10sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                                    
HID Mouse (pri  10sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                       
AUDIO/AHI-Handler 6.2  (pri   5sigrec 0x00000000sigwait 0x00000100masked 0x00000000)
                 
APPDIR/appdir-handler 54.21  (pri   5sigrec 0x00000100sigwait 0x80000000masked 0x00000000)
                            
USB stack Process (pri   0sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                         
MassStorage Notifier (pri   0sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                                  
DST watcher (pri   0sigrec 0x00000000sigwait 0xC0000000masked 0x00000000)
                               
NotifyA Server (pri   1sigrec 0x00000000sigwait 0xE8001000masked 0x00000000)
                         
string.gadget server (pri   1sigrec 0x00000100sigwait 0x40000000masked 0x00000000)
                            
datatypes.library (pri   1sigrec 0x00000000sigwait 0x80001000masked 0x00000000)
                       
RAM/ram-handler 54.26  (pri  10sigrec 0x00000100sigwait 0x80000000masked 0x00000000)
                       
ENV/env-handler 54.19  (pri   5sigrec 0x00000100sigwait 0x80000000masked 0x00000000)
                       
CON/con-handler 53.82  (pri   5sigrec 0x00000000sigwait 0xA0000100masked 0x00000000)
                       
RAW/con-handler 53.82  (pri   5sigrec 0x00000000sigwait 0xA0000100masked 0x00000000)
                       
CON/con-handler 53.82  (pri   5sigrec 0x00000000sigwait 0xA0000100masked 0x00000000)
                          
SFS DosList handler (pri  19sigrec 0x00000000sigwait 0x80000000masked 0x00000000)
                             
dos_nbmd_process (pri   5sigrec 0x00000000sigwait 0x00001100masked 0x00000000)
                             
dos_lock_handler (pri   5sigrec 0x00000000sigwait 0x00001100masked 0x00000000)
                                    
hub.usbfd (pri   0sigrec 0x00000000sigwait 0x30000000masked 0x00000000)
                                    
hub.usbfd (pri   0sigrec 0x00000000sigwait 0x30000000masked 0x00000000)
                                    
hub.usbfd (pri   0sigrec 0x00000000sigwait 0x30000000masked 0x00000000)
                                    
hub.usbfd (pri   0sigrec 0x00000000sigwait 0x30000000masked 0x00000000)
                      
p50x0sata.device Port 1 (pri  12sigrec 0x00000000sigwait 0xC0007000masked 0x00000000)
                     
Exec Command and Control (pri  30sigrec 0x00000000sigwait 0x80000000masked 0x00000000)

Suspended Tasks


Somether you see it fails at

(0x60689C70Work: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.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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?

Go to top


Re: have you seen this?
Just popping in
Just popping in


@kas1e

Cannot find Amiga WipeOut version to buy. That is one reason to port it.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: can anybody explain about current situation with BREL Relocations ?
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: can anybody explain about current situation with BREL Relocations ?
Just popping in
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.

Go to top


Re: can anybody explain about current situation with BREL Relocations ?
Just popping in
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.

Go to top


Re: can anybody explain about current situation with BREL Relocations ?
Just popping in
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)?

Go to top


Re: can anybody explain about current situation with BREL Relocations ?
Just popping in
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 ?

Go to top



TopTop
« 1 (2) 3 4 5 ... 8 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project