Using newlib-nano

[uknys]

Hello,

As I saw in the Readme, you said Newlib was too bloated for the PSX why not using newlib-nano variant for the purpose, as it's embedded in newlib right now and just depends on using the nano.specs as a baseline for the linker ?

Look at here to see the size decrease by using the newlib-nano variant : http://pabigot.github.io/bspacm/newlib.html

[mirh]

On the same bullet point, I'd also like the point out that a Linux kernel *does* exist on the PS1.

The only difficulty if any is that nobody has the original tool to format memory cards.

ook at here to see the size decrease by using the newlib-nano variant

There's also musl and uClibc btw.

[Lameguy64]

I'll take a look at that someday. I'm aware of the BIOS system functions that seem to resemble Linux/Unix functions, mainly the file I/O stuff but I don't think anything that depends on Linux would work on it as its not quite Linux, it merely just follows some Unix style stuff.

[mirh]

Not really sure how that relates to what I said, anyway just for the records, I know that in @frno7's plans for getting PS2 to mainline, all bios functions that can possibly be replaced and supplanted by the kernel will be so.

[frno7]

Perhaps klibc could work? I'm using parts of it for my forthcoming IOP module repository.

[ijacquez]

@mirh Is it possible to link newlib-nano without needing to rebuild the cross compiler?

It might be wise to add only what is really needed: a string library, and maybe a few other things.

To me, newlib-nano is great as it's optimized for embedded HW, but it offers a bit too much.

The other downside is that the header files are messy. They contain a lot of cruft, and it's hard to know what you really need. It pollutes the global namespace and possibly the result binary size.

Edit: It might be beneficial to say that malloc from newlib might not be the best choice. It might be more beneficial to offer a set of allocators: block-based, stack-based, and possibly a (slow and small) general-purpose allocator for allocations that are more long-term.

[mirh]

AFAIU the docs nano has to be passed both to the compiler and the linker.

On the other hand, my own point didn't really call for newlib, but more about considering all the tons of other options.

[ijacquez]

Got it. I think newlib-nano may not be a good choice. From what I see, it aims to have a fairly complete Unix-like environment. Something that is overkill.

@frno7 Maybe klibc might be good. The headers look fairly clean.

Another thing to consider is the ability to have the flexibility of rewriting certain functions in assembler. And newlib looks to be fairly embedded into the cross compiler, and that would make things a bit difficult.

[MrSapps]

To be honest would anyone writing a PSX game/app ever need an entire C standard lib anyway? Really you shouldn't be using the likes of fopen() to open a file on the CD-ROM drive for instance. I think you could get away with something very minimal that just supported the most commonly used things like sprintf/print and string manipulation stuff?

[ijacquez]

That's exactly right.

So what is a good string library that doesn't require ripping it out from a full C standard library? And is license compatible with Psn00bSDK?

[Lameguy64]

Would simply cloning the logic to get C++ classes and other basic features working enough to get around the license issue?

[ijacquez]

None of these projects listed are needed for C++ support. This and a few other files is what you need for C++ support.

You need these flags as well:

-fno-exceptions \
-fno-rtti \
-fno-unwind-tables \
-fno-threadsafe-statics \
-fno-use-cxa-atexit

You need this as well. You don't need the _init and _fini. You can stick these in the function that calls _main.

When you're compiling a C++ project, you link in c++-support.o into the list of objects, and all should be okay! Or I believe you can do something like:

#ifdef __cplusplus
...
#endif /* __cplusplus */

Which basic features are you referring to? Anything part of the C++ standard library? You might have to write/implement your own vector/list library, if that's what you're referring to.

[Lameguy64]

I'll give that a try once I find the time. I haven't really worked on the compiler/C++ side as I usually prioritize working on the hardware support libraries the most.

The basic C++ features I'm talking about are classes with constructors and deconstructors, as well as dynamically creating and deleting class objects using new and delete operators. I think C++ support in the official SDKs only went as far as the aforementioned basic support as I don't think there was std::string and std::vector implemented in those SDKs.

[MrSapps]

I think std::[anything] would be too heavy weight for PSX anyway. Using classes/C++ itself makes perfect sense though. Quite a few retail PS1 games used C++.

With the newer GCC version it should optimize much better to the point where simple objects are completely "gone" in the generated code too. One question does LTO work?

[ijacquez]

Yes, as an example, one of the Sponge Bob games on the PSX has had its source leaked. It uses C++.

And yes, just about anything from std namespace is too much.

What I've seen before is GCC identifying certain function signatures and outright replacing the function call with just a few instructions. That may be x86/x64 specific. It might need some compiler hints. Who knows.

I'm unfamiliar with LTO. How does it relate to the C library?

[Lameguy64]

I followed your suggested instructions and after a bit of fiddling, I finally got C++ working! Though getting it to work is a bit of a mess on the linker side as I have to put the C++ stuff in a separate library placed after libgcc and my libc subset library placed after. I'm considering changing the build process for for my C subset library by taking a copy of libgcc from the compiler and adding my own subset library's object files into it, to eliminate the resolution problems and consolidates everything to a single library file.

I only used code from c++-support.cxx as _call_global_ctors()/_call_global_dtors() didn't work for me as __DTOR_LIST__ isn't being defined anywhere, but that was enough to get classes and operators I want working. Constructors/deconstructions are not being executed however when the class is defined statically as a global, I guess that's what _call_global_ctors()/_call_global_dtors() is for.

[ijacquez]

Glad it worked out!

This is what you need in order to have the __.TOR_LIST__ symbols.

[ijacquez]

In case you haven't done so already, be sure to add

extern "C" {
#endif /* __cplusplus */

extern ...

#ifdef __cplusplus
}
#endif /* __cplusplus */

in your header files. You'll be then able to use C defined symbols in C++.

[Lameguy64]

After adding your suggested ldscript symbols to GCC's default ldscript, I finally got C++ fully working! I also did the aforementioned library consolidation with libc to make things a little cleaner. Thanks mate.

Now to figure out how to integrate the customized script as a linker default to shorten the ld command line. binutils seems to have a internalized copy of the script within the linker itself as it doesn't use the copy in the toolchain directories at all.

[ijacquez]

What do you mean by shorten the ld command line?

This is where it becomes a bit more complicated. The route I took was to install my library along with other necessary files (linker script, Makefiles, ...).

What I think you may want is writing a spec file. I have one in my repo: yaul.specs. Basically you just need to pass -specs=yaul.specs to GCC.

[MrSapps]

@ijacquez the LTO question is slightly off topic. It removes used functions and allows global optimizations. If you've ever decompiled any PS1 game there is tons of useless never referenced functions that don't get removed. Or code calling a function that is hard coded to return a certain value. LTO gets rid of all that stuff.

On GodBolt the mips compiler there has LTO disabled when the compiler was built. So I was wondering if it was somehow some limitation of mips although I can't see why it would be.

@Lameguy64 excellent working getting C++ working! 🎉

[Lameguy64]

Shorten the command line for ld by not having to specify the required ldscript whenever you link your programs. While not really a deal breaker especially when the linker is usually invoked in a makefile I thought it'd be a bit snappier to not have to manually specify the ldscript. I'll take a look at specs files at a later time, I rather take a break from working on PSn00bSDK for awhile as I want to focus on other projects for a bit.

I think GCC already does LTO out of the box, for one thing it completely omits functions that are not referenced by other functions within the came C file and my assembler functions are placed in individual files so that functions that aren't are omitted. For whatever reason if you have multiple functions in a single assembler file the other functions will always be included even if they aren't referenced anywhere in your program, I might be missing something when defining the function I suppose.

[MrSapps]

LTO is usually enabled with the -flto linker option. I think hand made ASM isn't subject to any kind of optimization what so ever which is why C can perform better when LTO is enabled.

Usually its like: gcc -o myprog -flto -O2 foo.c bar.c

[mirh]

PS2 is tentatively going to newlib btw
ps2dev/ps2sdk#104

[uyjulian]

ps2dev has always been using newlib for C++ code

[MrSapps]

Looks like that PR got closed because it caused crashes?

[mirh]

There's a new player in town: https://keithp.com/blogs/picolibc/
EDIT: ok somebody should make a PR for mips support, but still

[mirh]

Aaaand, it's done.