search

ps3dev / PSL1GHT

A lightweight PS3 SDK
www.psl1ght.com
MIT License
222 stars 62 forks source link

rsxInit() change brings issue with SDL libraries #106

Closed bucanero closed 4 years ago

bucanero commented 4 years ago

Just noted that recent changes in rsxInit() from https://github.com/ps3dev/PSL1GHT/commit/d0eea6e024a6e86435136b058bc7aaf1cabb0581 , brings some issues when building the SDL_PSL1GHT library from ps3libraries (013-sdl_psl1ght.sh)

e.g., you'll get a too few arguments to function 'rsxInit' error in SDL_PSL1GHTvideo.c

maybe other libs or samples are affected.

shagkur commented 4 years ago

Btw. i need your opinion on an other topic..... As you know i figured the issue with the SPRX stub macro and methods with more than 8 function arguments, for which i've been able to fix it (see psl1ght commit). However, currently this is done by 2 different macros (since as of now, only 2 PRX methods are affected), but i could collapse it to macro. The advantage: Only one macro used (code maintainability) but the downside would be: all export.h files need to be touched and the arg count needs to be set too (lots of boilerplate work). What do you think?

shagkur commented 4 years ago

We've always been incompatible with the FW OS ABI (which uses 32 bit pointers, for examples). That why we need wrappers.

Well this is some strange awkwardness within FW OS ABI anyways. Having a 64bit system and then fiddling around with 32bit pointers. And due to that i just think that a slight, not even harmful , change can affect the whole thing.

zeldin commented 4 years ago

The 32-bit pointers do kind of make sense considering the PS3 has <1GB of RAM... I think having two macros is fine. If you want to share some implementation I guess you could factor that out into a utility macro used by the other two?

shagkur commented 4 years ago

well atm they don't really share much. Wouldn't make sense to create a utility macro therefore. I guess, for now i keep it with 2 and if i'm really in the mood to spend hours of stupid copy over work, i'll collapse the 2 into 1.

zeldin commented 4 years ago

@shagkur I changed the default code model to "small" (max 64K TOC), and now the binary built in examples/2 is 100% identical to the one built with the old toolchain.

Note that there is no obvious reason why building with the "medium" model should make the code crash, this has nothing to do with ABI and is purely a code generation style option (the code uses a few more instructions for TOC lookups, but in return can handle TOC entries beyond the initial 64K). So it might be the case that there is a logical bomb type bug somewhere (in PSL1GHT, in irrlichtPS3, elsewhere) which just happened to become triggered by the code moving around a bit...

Its also a bit puzzling that you would get the "small" model before my changes (but I confirm that it does happen); both AIX and Linux use the "medium" code model by default in gcc 7 (in gcc 4 only "small" existed), and cell64lv2.h actually sets the model to "medium"...

shagkur commented 4 years ago

@zeldin Have you been able to run the example on HW? or do you mind to send me your build version of the example, so i can test here? This sounds really a bit strange. It's forcefully set to medium but previous gcc 7 toollchain built produced athe small model? The only location where i could imagine an issue with TOC handling is the SPRX stub macro along with the SPRX linker? Especially if the resulting binary gets "big" enough, what it does imo with the irrlichtPS3 example. Well, i was kinda surprised too that it all of a sudden crashed with irrlichtPS3. Because the rsxtest samples all worked. Currently i'm again on the commit before your change, but if you want (and if it's of any help for you) i can built with the recent version and run the example and then send you the backtrace?

zeldin commented 4 years ago

I haven't tested it on HW yet, I'm making a full rebuild of everything now, I can send you the resulting binary afterwards.

Well, it wasn't forceful, it was just the default, but it was this default setting that I could change from "medium" to "small" to get the small model back afterward. There's probably a logical explanation for this, I just didn't see it without instrumentation of the code, and doing that seemed a little overkill. :smile:

Regarding "big" binaries, the "medium" model actually makes the TOC smaller, and also can handle larger TOCs, so if anything it should work better with big binaries than the "small" model does... It's all very weird.

Well, if you have a backtrace maybe it could shed some light (l1ght?) on things. Feel free to collect one and pastebin it.

zeldin commented 4 years ago

@shagkur Here are the binaries I build with everything from master: https://mc.pp.se/irrlicht_example_2.zip I also tested it on PS3 hardware and it worked fine (showing some stone steps and a moving light source).

shagkur commented 4 years ago

That sounds promising. Yeah, it's not that fancy example, but if it wouldn't work it'd crash immediatly.

shagkur commented 4 years ago

@zeldin Here's the built from the "nonworking" toolchain with the stacktrace: 2_crash.zip Oh, and yes, your build works fine :)

zeldin commented 4 years ago

Looks like it's crashing in pngDecCreate, but the actual crash is down inside libpngdec.sprx somewhere. So I guess it got bad arguments from the caller (irr::video::CImageLoaderPNG::CImageLoaderPNG()) or something?

shagkur commented 4 years ago

Okay. hmm...need to take a look then. Kinda strange it's not triggering the crash with the small model?