-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nxdk has no proper libc #13
Comments
Maybe this is the right time to talk about what I've been doing.
Missing parts like printf could get picked from the CC0-licensed "pdclib", which some of my code is already based on. There are several more things I worked on or experimented with like an OpenAL-implementation with some tricks to make it run faster than existing ones, C++ support and support for thread-specific storage (which is especially tricky because cxbe simply ignores TSS). However, there are reasons why I didn't already contribute to nxdk or base my XDK on OpenXDK code.
Since there is little hope that I can find enough time to make my own project as capable as nxdk currently is. I am interested in joining forces. There my be need for a discussion if and how this can be done, however. |
Sounds good. I hope you put your code online soon.
clarification: so is ours, but the one created by mingw does not work, I'm not sure how to do it with clang and I don't want to run Windows just to generate a new lib.
This one bothers me in nxdk and I'll probably tackle it soon out of frustration.
Doesn't NtVirtualAlloc already take care of that? Maybe I'm mistaken though. I never really looked into the MS memory allocator
(My response has moved to #20 )
Very interesting if you can get that to work somehow
This should be easily fixable (I think).
(My response has moved to #21 )
Agreed. I'm super annoyed by the Makefiles anyway and I'd have preferred CMake, let alone the cluttered *.c and *.c.d files.
|
I was under the impression that
Agree. @thrimbor, if you want to do the work to make it better, by all means. By the way, IIRC OpenXDK got sound working with SDL. Might be a good place to start, but YMMV.
Simple C++ support is not hard to add. You just need to handle some of the C++ ness (make sure you call the static (de-)constructors appropriately). I think the STL stuff will be handled by the compiler and doesn't need any special support. Object instantiation (via
What's with all the Makefile hate? 😄 As for the clutter, we can move the build artifacts (*.d, *.o, and friends) into a "build" directory instead of having them sit next to their source counterparts. -- Now that NXDK has grown to include a lot more functionality, I think the libraryization of things makes sense, and would be cleaner...if someone wants to do the work for any of this (I'm not bothered enough by it at the moment to invest the time).
Coincidentally, my IRC bouncer is also down.. for the last month or so. I get the GitHub e-mails about comments, so I can usually respond to those within a couple days, depending on content and if I'm not too busy. @JayFoxRox I like IRC, but maybe setting up a gitter.im for XQEMU would lower the barrier of entry for new developers... thoughts? |
Unfortunately not, it doesn't provide a heap, it's really just allocation of pages for the virtual address space. That's also why it allows you to specify pagetable flags ;) Quick & dirty test:
A full page for every one-byte allocation.
I was working on porting libc++, which has quite a few requirements to work correctly. It has been a while since I worked on this, and I put it aside when I couldn't find the time to investigate name-mangling issues. I might work on bringing over my kernel headers and libc to NXDK in the next few days, but that depends on whether I can find the time. |
I think my code with All XBEs I've come across have their own libc routines embedded. They are really For thread compatibility, definitely This is a good idea. |
Can you elaborate on how api translation would make nxdk work better? xexec does kernel API to POSIX, but nxdk builds executables targeting Xbox and kernel API so you would want to go the other direction. That's right, with exception to xbe kernel imports and any custom dynamic linking stuff (xbmc does this for instance), all libs are statically linked. My preference for nxdk is to keep things as simple as possible and to not introduce any hard dependencies. That said, I'm open to considering a better libc library, especially a better printf (which there are many even public domain implementations). I plan on adding one eventually, but would happily merge a PR if someone wants to do it. If someone wants to add some library for POSIX support (eg pthreads), that would be great too. PRs welcome. |
I want to take a crack at porting newlib. Before I dive too deep into this, does anyone know of any reason why our libc shouldn't be newlib for the foreseeable future? |
printf
is absolutely horrible and doesn't respect most format specifiers (not Xbox specific).A better minimalistic alternative is even present in cromwell
fopen
and friends are missing (Xbox specific).I'd like to hear about peoples opinion which libc we should use or if we should implement our own.
I have never ported a libc and I'm not sure how C++ compatibility would play into this in the future.
I'm also not sure how a libc would handle the platform specific parts in contrast to the non-platform specific parts (such as the
printf
stuff)However, this is an important issue which causes a lot of trouble in any Xbox related homebrew I have.
The text was updated successfully, but these errors were encountered: