Ps2toolchain: ELF फ़ाइल के अंतिम बाइट कभी-कभी दूषित हो जाते हैं

आश्चर्यजनक है कि आप उस निष्कर्ष पर कैसे पहुंचे

अगर ऐसा लगता है कि ईएलएफ के भीतर मूल्य अच्छे हैं, तो आपको क्यों नहीं लगता कि यह एक ps2link समस्या है? क्या होगा यदि आपने अपना ईएलएफ लोड करने के लिए किसी अन्य विधि का उपयोग किया है?
मुझे लगता है कि यह संभवतः ps2link स्मृति को साफ़ नहीं करने के कारण होता है। sceSifLoadElf() फ़ंक्शन किसी भी मेमोरी को शून्य नहीं करता है, इसलिए खराब डेटा दिखाई दे सकता है यदि उस फ़ंक्शन के साथ ELF लोड होने से पहले मेमोरी को मिटाया नहीं जाता है।

अगर ऐसा लगता है कि ईएलएफ के भीतर मूल्य अच्छे हैं, तो आपको क्यों नहीं लगता कि यह एक ps2link समस्या है? क्या होगा यदि आपने अपना ईएलएफ लोड करने के लिए किसी अन्य विधि का उपयोग किया है?

हाँ, ELF फ़ाइल में डेटा अच्छा लगता है, इसलिए मुझे लगता है कि इस मुद्दे का शीर्षक थोड़ा भ्रामक है। मैं एक और लोडर की कोशिश करूँगा।

मुझे लगता है कि यह संभवतः ps2link स्मृति को साफ़ नहीं करने के कारण होता है। sceSifLoadElf() फ़ंक्शन किसी भी मेमोरी को शून्य नहीं करता है, इसलिए खराब डेटा दिखाई दे सकता है यदि उस फ़ंक्शन के साथ ELF लोड होने से पहले मेमोरी को मिटाया नहीं जाता है।

const int in .sdata (स्थिर डेटा) अनुभाग में हैं। मुझे लगता है कि .sdata अनुभाग को एल्फ फ़ाइल से स्मृति में 16bytes/128bits की इकाइयों में कहीं कॉपी किया गया है। शायद अगर .sdata सेक्शन 128बिट्स का गुणज नहीं है, तो शेष डेटा कॉपी नहीं किया जाता है, इसके स्थान पर शून्य छोड़ दिया जाता है?
या शायद .sdata अनुभाग सही ढंग से कॉपी किया गया है, लेकिन एक और शून्य अनुभाग इसके आगे ठीक से संरेखित नहीं है? और जीरोइंग .sdata के कॉपी होने के बाद होता है?

नमस्ते,
यह देखने के लिए कि क्या @sp193 सही था और समस्या ps2link में थी, मैंने उदाहरण को संशोधित किया है और अब यह स्क्रीन में आउटपुट देखने के लिए scr_prinf फ़ंक्शन का उपयोग करता है और आसानी से निष्पादित किया जा सकता है ULaunchELF या PCSX2 . में लोड किया गया

फ़ाइल की सामग्री

#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;

संकलन प्रक्रिया

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

आउटपुट, इस मामले में, PCSX2 . का उपयोग कर

जैसा कि आप देख सकते हैं कि परिणाम वही है जो @rickgaiser ने टिप्पणी की थी।

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

धन्यवाद

ps2link योगिनी फ़ाइल को लोड करने के लिए SifLoadElf फ़ंक्शन का उपयोग करता है:
https://github.com/ps2dev/ps2link/blob/1ec566c54bb8b567ee0a702982b392f37807b5e2/ee/cmdHandler.c#L138

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

यह IOP पर RPC फ़ंक्शन को कॉल करना समाप्त करता है। लोडफाइल का हिस्सा।

क्या यह LOADFILE में एक बग हो सकता है? या शायद हमारा टूलचेन अनुभागों को उस तरह से संरेखित नहीं करता है जिस तरह से LOADFILE उनसे अपेक्षा करता है? क्या sbv_patches इस समस्या को ठीक कर सकते हैं? मैं देख सकता हूं कि वे LOADFILE को पैच करते हैं, लेकिन क्या वे इससे संबंधित कुछ भी पैच करते हैं?

LOADFILE के लिए SBV पैच LoadModuleBuffer() के लिए RPC फ़ंक्शन को सक्षम करना था। किसी कारण से, वह फ़ंक्शन LOADFILE के प्रारंभिक संस्करण द्वारा समर्थित नहीं है। सोनी इसे भी पैच करता है, इसलिए यह स्पष्ट रूप से कुछ ऐसा है जिसे अनदेखा कर दिया गया था।

मुझे बग मिला:

crt0 16byte/128bit की इकाइयों में .bss अनुभाग को साफ़ करता है। इसके लिए .bss अनुभाग को कम से कम 16byte/128bit से संरेखित करना आवश्यक है। पहले यह ps2sdk में लिंकरफाइल द्वारा गारंटीकृत था। हालांकि, बिनुटिल्स में डिफ़ॉल्ट लिंकरस्क्रिप्ट (मैंने यहां जोड़ा: https://github.com/ps2dev/ps2toolchain/commit/7c494f217d379639aaca23d3c588e48986177a51) crt0 के लिए .bss अनुभाग को ठीक से संरेखित नहीं करता है। .sdata में अंतिम कुछ मानों के परिणामस्वरूप भी साफ़ किया जाना है।

मैंने यहां बिल्टिन बिनुटिल्स लिंकरस्क्रिप्ट के लिए एक फिक्स बनाया है। यह न्यूलिब पीआर का हिस्सा होगा।

आईआईआरसी, आप हमेशा यह सुनिश्चित करना चाहते हैं कि अनुभाग 128-बिट संरेखित हैं। मेरा मानना ​​​​है कि यह डीएमए संरेखण या कुछ ऐसे के साथ कुछ करना था लेकिन निश्चित नहीं था।

इस मुद्दे को न्यूलिब पीआर के साथ हल किया गया है जिसे हाल ही में विलय कर दिया गया है, विशेष रूप से यह प्रतिबद्धता: https://github.com/ps2dev/ps2toolchain/commit/f5544b8d68fbdf611e277e9583714ae6627f3a61