Ps2toolchain: Byte terakhir file ELF terkadang rusak

Dibuat pada 15 Jan 2020 · 9Komentar · Sumber: ps2dev/ps2toolchain

Potongan kode berikut akan menghasilkan output yang tidak valid:

#include <stdio.h>

extern const int i1, i2, i3, i4;

int main()
{
        printf("i1=%d\n", i1);
        printf("i2=%d\n", i2);
        printf("i3=%d\n", i3);
        printf("i4=%d\n", i4);

        return 0;
}

const int dum1=1;
const int dum2=2;
const int dum3=3;
//const int dum4=4;
//const int dum5=5;
//const int dum6=6;
const int i1=1111;
const int i2=2222;
const int i3=3333;
const int i4=4444;

Ketika dicoba dengan jumlah konstanta dummy acak, hasilnya akan bervariasi dari:
Bagus:

i1=1111
i2=2222
i3=3333
i4=4444

Buruk:

i1=1111
i2=2222
i3=3333
i4=0

i1=1111
i2=2222
i3=0
i4=0



md5-a7a998816ff6355b19ebaf6bb16f20b1



i1=1111
i2=0
i3=0
i4=0



md5-50fa41c3352404f2cadd42c17104c34f



ee-gcc -o hello.elf hello.c
ps2client -h 192.168.1.10 execee host:hello.elf

Bug ini menyebabkan size_ds34bt_irx dan/atau size_ds34usb_irx di OPL menjadi 0. Menyebabkan crash acak OPL saat boot (layar hitam). Menambahkan baris kode di tempat acak di OPL, akan menyebabkan bug ini muncul dan menghilang.

Nilai yang tidak valid tampaknya berada di 128bit terakhir file ELF, jika dilihat menggunakan:
ee-objdump -D hello.elf

Nilai dalam file elf bagus, jadi sepertinya ada yang salah saat memuat elf.

Sumber

rickgaiser

👀1 👍1

Komentar yang paling membantu

Saya menemukan bug:

crt0 menghapus bagian .bss, dalam satuan 16byte/128bit. Ini membutuhkan bagian .bss untuk disejajarkan dengan setidaknya 16byte/128bit. Sebelumnya ini dijamin oleh linkerfile di ps2sdk. Namun, skrip tautan default di binutils (saya tambahkan di sini: https://github.com/ps2dev/ps2toolchain/commit/7c494f217d379639aaca23d3c588e48986177a51) tidak menyelaraskan bagian .bss dengan benar untuk crt0. Menghasilkan beberapa nilai terakhir dalam .sdata yang akan dihapus juga.

Saya telah membuat perbaikan untuk skrip tautan binutils bawaan di sini . Ini akan menjadi bagian dari PR newlib.

rickgaiser pada 15 Jan 2020

🚀1 👍1

Semua 9 komentar

Luar biasa bagaimana Anda mencapai kesimpulan itu

fjtrujy pada 15 Jan 2020

Jika sepertinya nilai di dalam ELF bagus, mengapa menurut Anda itu bukan masalah ps2link? Bagaimana jika Anda menggunakan metode lain untuk memuat ELF Anda?
Saya pikir itu mungkin disebabkan oleh ps2link tidak menghapus memori. Fungsi sceSifLoadElf() tidak nol memori apapun, maka data yang buruk dapat muncul jika memori tidak dihapus sebelum ELF dimuat dengan fungsi itu.

sp193 pada 15 Jan 2020

Jika sepertinya nilai di dalam ELF bagus, mengapa menurut Anda itu bukan masalah ps2link? Bagaimana jika Anda menggunakan metode lain untuk memuat ELF Anda?

Ya, data dalam file ELF sepertinya bagus, jadi saya kira judul masalah ini sedikit menyesatkan. Saya akan mencoba pemuat lain.

Saya pikir itu mungkin disebabkan oleh ps2link tidak menghapus memori. Fungsi sceSifLoadElf() tidak nol memori apapun, maka data yang buruk dapat muncul jika memori tidak dihapus sebelum ELF dimuat dengan fungsi itu.

Int const ada di bagian .sdata (data statis). Saya pikir bagian .sdata disalin dari file elf ke memori dalam satuan 16bytes/128bits di suatu tempat. Mungkin jika bagian .sdata bukan kelipatan 128bit, data yang tersisa tidak disalin, meninggalkan nol di tempatnya?
Atau mungkin bagian .sdata disalin dengan benar, tetapi bagian nol lainnya tidak disejajarkan dengan benar di sebelahnya? Dan zeroeing terjadi setelah .sdata disalin?

rickgaiser pada 15 Jan 2020

Halo,
Untuk melihat apakah @sp193 benar dan masalahnya ada di ps2link Saya telah memodifikasi contoh dan sekarang menggunakan fungsi scr_prinf untuk melihat output di layar dan mudah dijalankan oleh ULaunchELF atau dimuat ke PCSX2

Isi filenya

#include <stdio.h>

void init_scr(void);
void scr_printf(const char *, ...) __attribute__((format(printf,1,2)));

extern const int i1, i2, i3, i4;

int main()
{
   init_scr();
   scr_printf("i1=%d\n", i1);
   scr_printf("i2=%d\n", i2);
   scr_printf("i3=%d\n", i3);
   scr_printf("i4=%d\n", i4);

   while(1) {}

   return 0;
}

const int dum1=1;
const int dum2=2;
const int dum3=3;
const int dum4=4;
const int dum5=5;
const int i1=1111;
const int i2=2222;
const int i3=3333;
const int i4=4444;

Proses kompilasi

ee-gcc -o hello.elf hello.c -L$PS2SDK/ee/lib -ldebug

Outputnya, dalam hal ini, menggunakan PCSX2
Screenshot 2020-01-15 at 09 47 54

Seperti yang Anda lihat, hasilnya sama dengan komentar @rickgaiser .

i1=1111
i2=2222
i3=3333
i4=0

Terima kasih

fjtrujy pada 15 Jan 2020

🚀1

ps2link menggunakan fungsi SifLoadElf untuk memuat file elf:
https://github.com/ps2dev/ps2link/blob/1ec566c54bb8b567ee0a702982b392f37807b5e2/ee/cmdHandler.c#L138

dari ps2sdk:
https://github.com/ps2dev/ps2sdk/blob/5385a6ccd9db8c9fa54ecfd8af45322a5908bf6d/ee/kernel/src/loadfile.c#L129

Itu akhirnya memanggil fungsi RPC di IOP. Bagian dari LOADFILE.

Mungkinkah ini bug di LOADFILE? Atau mungkin rantai alat kami tidak menyelaraskan bagian seperti yang diharapkan LOADFILE? Bisakah sbv_patches memperbaiki masalah ini? Saya dapat melihat mereka menambal LOADFILE, tetapi apakah mereka menambal sesuatu yang terkait dengan ini?

rickgaiser pada 15 Jan 2020

Patch SBV untuk LOADFILE adalah untuk mengaktifkan fungsi RPC untuk LoadModuleBuffer(). Untuk beberapa alasan, fungsi tersebut tidak didukung oleh versi awal LOADFILE. Sony juga menambalnya, jadi ini jelas sesuatu yang diabaikan.

sp193 pada 15 Jan 2020

Saya menemukan bug:

Saya telah membuat perbaikan untuk skrip tautan binutils bawaan di sini . Ini akan menjadi bagian dari PR newlib.

rickgaiser pada 15 Jan 2020

🚀1 👍1

IIRC, Anda selalu ingin memastikan bagian disejajarkan 128-bit. Saya yakin itu ada hubungannya dengan penyelarasan DMA atau semacamnya tetapi tidak yakin.