Broken C++ support in prx modules

[Crow-bar]

The GCC compiler, when data is forcibly placed in the .sdata section, generates a load via the $gp register. This can be easily verified by creating a module with built-in libc. It will work from the entry point(module_start) and will not work if you use API calls from the head module.

The -mno-gpopt flag for gcc(libstdc++/libsupc++) and newlib libraries should solve this problem.

[davidgfnet]

I thought we built everything with "-G0", is that not sufficient to avoid using gp as global pointer or just a "hack"?

[Crow-bar]

I thought we built everything with "-G0", is that not sufficient to avoid using gp as global pointer or just a "hack"?

-G0 does not disable addressing relative to $gp, but only sets the maximum size of variables that will be automatically placed in .sdata.

Target libraries use forced placement of data in .sdata using an attribute, for example (Newlib) _impure_ptr:

#define __ATTRIBUTE_IMPURE_PTR__ __attribute__((__section__(".sdata")))

struct _reent *__ATTRIBUTE_IMPURE_PTR__ _impure_ptr = &impure_data;
struct _reent *const __ATTRIBUTE_IMPURE_PTR__ _global_impure_ptr = &impure_data;

I also think the -G0 parameter should be removed from build.mak and build_prx.mak so that users can decide whether they need it or not.

[fjtrujy]

Feel free to create PR for this!

[davidgfnet]

To be honest I never understood why we do not use $gp. In the past (I recall like 10+years ago) we definitely had support for this (and used some default value like -G4 or -G8). So if I understand correctly you are saying that in some cases, whenever calling to a PRX module, $gp doesnt hold the right value, right? Is this a user .prx ? I lack the knowledge on how different modules (for instance in linux a bunch of ELFs/.so) can use the $gp, since each module might have its own global pool. But yeah it's not an issue, we could add -mno-gpopt for the library builds and remove the -G0. Then let the user decide whether they want to use -G0 or not.

[Crow-bar]

To be honest I never understood why we do not use $gp. In the past (I recall like 10+years ago) we definitely had support for this (and used some default value like -G4 or -G8). So if I understand correctly you are saying that in some cases, whenever calling to a PRX module, $gp doesnt hold the right value, right? Is this a user .prx ? I lack the knowledge on how different modules (for instance in linux a bunch of ELFs/.so) can use the $gp, since each module might have its own global pool. But yeah it's not an issue, we could add -mno-gpopt for the library builds and remove the -G0. Then let the user decide whether they want to use -G0 or not.

The old version of psp newlib had the -mno-explicit-relocs (Do not use assembler relocation operators when dealing with symbolic addresses.) flag. This flag also disables $gp relative addressing in certain cases.

MIPS Linux uses the -fPIC, -shared flags, which either disable the use of $gp or restore it on each call.

[Crow-bar]

The official psp sdk uses the gp_safe attribute for exported functions. It would be good to learn how it works

[diamant3]

I also think the -G0 parameter should be removed from build.mak and build_prx.mak so that users can decide whether they need it or not.

Hello @Crow-bar do you have any plan to make a PR on this one? so we can consolidate your PR to pspdev/gcc#6 and pspdev/newlib#8, if you don't mind :relaxed:, thank you!

[Crow-bar]

I also think the -G0 parameter should be removed from build.mak and build_prx.mak so that users can decide whether they need it or not.

Hello @Crow-bar do you have any plan to make a PR on this one? so we can consolidate your PR to pspdev/gcc#6 and pspdev/newlib#8, if you don't mind ☺️, thank you!

Hello, yes

[diamant3]

Thanks for the PRs! alright, let me see all of that first if there's no issue

[Crow-bar]

Need to fix psplink and pthread

[Crow-bar]

Checking flags in psp-packages requires a lot of work

[fjtrujy]

Checking flags in psp-packages requires a lot of work

Majority of the libraries use cmake for compilation, so it shouldn’t be that difficult

[diamant3]

Hello @Crow-bar are you still working on this? if not, could you let me handle this so we can close this issue

[Crow-bar]

Hello @Crow-bar are you still working on this? if not, could you let me handle this so we can close this issue

Hello! You can close it.

I'm currently trying to solve a problem with importing variables.