hvcall_341.c:28:2: error: PIC register clobbered by 'r2' in 'asm' __asm__ __volatile__(

[crystalct]

Using last ps3toolchain (gcc 7.2). PowerPC / PowerPC64 / RS6000 GCC now diagnoses inline assembly that clobbers register r2. This has always been invalid code....

[bucanero]

I think that removing "r2" references from all the payload sources should be enough to fix the clobbered issue. At least that's what we did with Tiny3d , right?

[aldostools]

I use this toolchain and don't get that error: https://github.com/Estwald/PSDK3v2

Extract this include.zip in the following path for the additional features added to the toolchain (unrar, un7zip, ff, etc.) C:\PSDK3v2\ps3dev\portlibs\ppu\include

[bucanero]

yes, the r2 register didn't bring any issue with the older gcc 4 toolchain, but with gcc 7 it doesn't compile.

recently @crystalct was updating the tiny3d lib to the latest toolchain and we've got that error. We removed the r2 from the inline and it worked alright. I'm just not sure if removing r2 works ok with the gcc4 toolchain or not.

[bucanero]

@aldostools , I've forked and applied the register patch on my fork

whenever you have a chance, could you check if you can compile Irisman with that change (https://github.com/bucanero/IRISMAN/commit/0350bb77d19a15899ed71c83f7eef2d9a2470c2f) too using Estwalds toolchain? if the patch also works on your end then I can submit a PR and we keep the change for everyone

[aldostools]

I built your fork and it compiled fine.

Since your changes were in hvcall.c of the initial payloads 3.41 and 3.55, I cannot validate if they work fine on the PS3 or not.

I'm using 4.86.1 Rebug Lite, and that code is executed only when IRISMAN starts on these FW versions.

[bucanero]

thanks for try it out! 👍

does anyone still uses fw 3.41 or 3.55? shall we go ahead and merge the fix? what do you think?

I'd say that we can just merge this change, and if someone with such old firmware ever tries it out, we'll get some feedback and rollback the change if it didn't work.

let me know your ideas 😄

[aldostools]

I'm don't like the idea of change a working code... I could add a comment about removing "r2" if cause issues with GCC 7.

I never had reports about it and this change could break it for CFW users.

I'm not aware of people still using 3.41, but 3.55 is still used by many people for downgrades and troubleshooting.

[bucanero]

I'm don't like the idea of change a working code... I could add a comment about removing "r2" if cause issues with GCC 7.

well, if you prefer, we could do a conditional #ifdef (like crystal did on Tiny3d), for example:

// GCC now diagnoses inline assembly that clobbers register r2. 
// This has always been invalid code, and is no longer quietly tolerated.
#if __GNUC__ >= 7       
          :"r0", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12", "lr", "ctr", "xer",
#else
          :"r0", "r2", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12", "lr", "ctr", "xer",
#endif

that way the source will keep the original code when compiling with GCC 4 (Estwald), and will use the the updated code only if we use the new toolchain with GCC 7+

I never had reports about it and this change could break it for CFW users.

from my experience, a lot of people uses Windows and usually just downloads Estwald's SDKv2. Since they never tried building the toolchain from scratch, they won't have the newer gcc 7.2 (and won't find any issues building it)

I'm not aware of people still using 3.41, but 3.55 is still used by many people for downgrades and troubleshooting.

let me know what you think about the #ifdef alternative, I think it's the best way to have the fix while keeping the original code for older gcc compiler.

[crystalct]

If someone try to compile It with new toolchain, he cant....so checking GCC version Is a solution self-evident...imho

Il mar 18 ago 2020, 16:03 Damián Parrino notifications@github.com ha scritto:

I'm don't like the idea of change a working code... I could add a comment about removing "r2" if cause issues with GCC 7.

well, if you prefer, we could do a conditional #ifdef (like crystal did on Tiny3d), for example:

// GCC now diagnoses inline assembly that clobbers register r2. // This has always been invalid code, and is no longer quietly tolerated.

if GNUC >= 7

      :"r0", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12", "lr", "ctr", "xer",

else

      :"r0", "r2", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12", "lr", "ctr", "xer",

endif

that way the source will keep the original code when compiling with GCC 4 (Estwald), and will use the the updated code only if we use the new toolchain with GCC 7+

I never had reports about it and this change could break it for CFW users.

from my experience, a lot of people uses Windows and usually just downloads Estwald's SDKv2. Since they never tried building the toolchain from scratch, they won't have the newer gcc 7.2 (and won't find any issues building it)

I'm not aware of people still using 3.41, but 3.55 is still used by many people for downgrades and troubleshooting.

let me know what you think about the #ifdef alternative, I think it's the best way to have the fix while keeping the original code for older gcc compiler.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aldostools/IRISMAN/issues/11#issuecomment-675497873, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMY7LNFS2VUKCRXCZPYDPLSBKC4XANCNFSM4NV7BHJA .

[bucanero]

thanks @aldostools for adding the fix! 👍

[aldostools]

Thanks to you @bucanero & @crystalct for the fix.