-
Notifications
You must be signed in to change notification settings - Fork 0
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
Static executable v2 rebase against sbcl master #2
base: master
Are you sure you want to change the base?
Conversation
There is one commit that is slightly different for the 2.2.6 release, so I did a separate rebase for that one. https://github.com/tgbugs/sbcl/tree/static-executable-v2-2.2.6 |
Looks like there are some new issues that don't seem to appear in the 2.2.0 version. I don't a full understanding, but the missing symbols seem to be from the sbcl core and libc?
|
Possibly avoids dynamic space relocation on FreeBSD. It seems to add a random number to any addresss you give it, which means that R/O always collided with dynamic.
Don't scan inherited symbols. This was about 4x faster in a system having 1000 packages, each using on average 10 other packages, and where many distinct symbols are spelled the same.
Do not assume that 'cc' is executed in src/runtime. In particular, allow the root of SBCL's source tree to be one or more levels down from where the compiler gets invoked. This places different demands on where autogenerated headers are written to by 1st genesis and where they are read from by make-target-1 (or equivalent). And non-system includes should not use <> syntax (in main.c)
https://wiki.freebsd.org/WarnerLosh/UsrLocal says something about it. Should fix lp#1981112.
It doesn't work well on instance types, producing wider types.
Fixes lp#1979841
This is a modified version of Douglas Katzman's commit 869f2ac (Remove non-pauseless-threadstart code), which gets the pauseless-threadstart feature to work on Windows. Since Windows is the last outstanding platform that builds with pauseless-threadstart disabled by default, this commit also removes the pauseless-threadstart feature flag entirely. The original commit was modified so that it applies to 2.2.7 as well as to remove the setup semaphore and to set th->no_tls_value_marker to NO_TLS_VALUE_MARKER in alloc_thread_struct. Note: The original commit was reverted by 15f2ccc (Revert "Remove non-pauseless-threadstart code") due to failing tests.
I caused it in rev 3395391 by outdenting the WHEN without the TYPECASE. They were both wrongly indented but I made it worse.
* a page with no object headers should have 0 generation mask, both in coreparse and after sweeping * correctly zero-fill after the object offset array when saving * and brothertree.h was sensitive to inclusion order
While we're at it, remove purify.c as irrelevant.
Slightly related- alphabetize the #include lines.
The wired address was just for debugging.
TLSF isn't used, but eventually I'd like all the 64-bit architectures to have immobile-space. That time is not now.
Rev 0e3d1d6 which fixed the build failure reported in https://groups.google.com/g/sbcl-devel/c/1oraPq21KnA/m/QT42XSLiCQAJ for ppc64 caused a crash for ppc32 (and other 32-bit configs with LRAs and threads - but there aren't any) I couldn't figure out why it kept working under cross-make for me, but banging my head against the desk sufficiently many times resulted in my recalling that my native-on-native ppc32 build had #+sb-thread.
Lots of tests fail for not-too-scary reasons such as compiler notes, CLOCK-GETTIME not being a thing, too much consing in assert-no-consing, readlink not working the same as we expect (wtf?) etc, etc. Probably the most interesting one was "unknown SC to SC-CASE" from foreign.test.sh which revealed that SINGLE-FLOAT-BITS doesn't cover all the cases allegedly permitted for its args/results. But without this patch, half the suite failed with C runtime lossage in all sorts of colorful ways. So ... just I can't even.
And rob 1 bit of that, so it's effectively 15 bits, not 16. Then free up 2 more bits of 'type' for other use as I tried to do in rev 938320b which was reverted. Taking a different bit in the PTE should be fine, and the resulting code looks better for it.
When the number of more arguments overflow local-tn-limit they are assigned the same number. Avoid doing that twice for a duplicate TN. Reported by Qian Yun.
Fixes a "buffer overrun" error
I don't know why rev 3bdd4d2 took out the lines (unless (cold-null (cold-fdefn-fun fdefn)) (error "Duplicate DEFUN for ~S" warm-name)) from COLD-FSET, but it did, and of course in the interim there was backsliding such that there is now a duplicate. And lexical vars named DEFN and FDEFN are too confusing to co-exist in the same function, so fix that.
On #+unix it's always and nothing but munmap(). os_deallocate() is a better name, so just make the obvious alterations.
which failed to compile ever since rev b8ff0a4 ("pass a GC space id") but became more bitrotted with the recent rename of T to LISP_T. Too many C warnings in that janky logic to know what's going on anyway.
Without a shred of documentation in sight, I'm guessing that this is what's needed to fix the problem reported in https://sourceforge.net/p/sbcl/mailman/message/37703368/ Not gonna try this patch on the other architecture/OS combinations that seem to lack the proper incantation, so we'll at least know if we're fixing bugs in a vacuum (based on complaints or lack of).
and I don't know what "alignment passed from os_validate" means, so rewrite that comment block.
Nobody I surveyed guessed correctly that "validate" meant "give me memory"
7525ae4
to
7729ff3
Compare
Add a new C function - arch_read_linkage_entry - that backs out the true foreign address of the corresponding symbol from the data in the linkage table. Add a Lisp function - FIND-LINKAGE-TABLE-FOREIGN-SYMBOL-ADDRESS - that uses this new C function to return the address, while accounting for undefined symbols (so as to not accidentally return a reference to a guard page).
If we can't get a runtime handle, we can't be sure that FIND-DYNAMIC-FOREIGN-SYMBOL-ADDRESS will work, so teach FIND-FOREIGN-SYMBOL-ADDRESS to look up symbols via dlsym or by backing out the address from the linkage table. Replace most calls to FIND-DYNAMIC-FOREIGN-SYMBOL-ADDRESS with FIND-FOREIGN-SYMBOL-ADDRESS. This gets us a step closer to having #-os-provides-dlopen work. Additionally, this lets us create a static executable with musl libc. Musl's libdl functions all return an error when called within a static executable. At the moment, the only way to take advantage of this is shrinkwrapping, as a working libdl is required to build a working Lisp core from scratch.
Additionally, remove the comment fro the comma variable definition. On at least GNU make 4.3, the value is set to ", ", not ",".
Patch originally by Manuel Giraud <[email protected]>, I just cleaned up some comments. Also preemtively remove after-grovel-headers since upstream removed it and it will make the rebase easier.
This is an internal feature. When present, genesis writes a C helper file (linkage-table-prelink-info.c) that populates the C var lisp_linkage_values. This variable (originally introduced as part of the shrinkwrapping support) contains the true addresses of each variable and function in the linkage table. Then, when the runtime boots instead of using os_dlsym_default and required-foreign-symbols to fill the linkage table, the data in lisp_linkage_values is used instead. This has the affect of using the system linker to prelink the entire linkage table instead of doing it ourselves. Last, when the core boots, it has to fixup the prelinked entries. This is required to make sure the linkage table points to the appropriate guards for undefined foreign variables or functions. This cannot be done in the runtime because some on some archs the undefined alien function guard is an assembly routine generated in lisp. Instead, a NULL entry in lisp_linkage_values indicates an undefined entry. A useful feature for some use cases is to add extra symbols to the linkage table at build time that we know we'll need at run time. This is accomplished by passing the extra entries to the make process using the --extra-linkage-table-entries argument. The file must contain a single list. Each element is a linkage table entry consisting of three elements. The first is a string naming the C symbol. The second is T if the symbol is a variable, NIL if it is a function. The third is T if the entry is undefined (this is currently pointless, but will become useful in a future commit). Enabling this feature on Windows causes a test failure. The root cause is that mingw-w64 implements its trig functions as thin wrappers around fsin and friends. This can be wildly inaccurate. When this feature is enabled, the trig functions come from wingw-w64's libm. When this feature is disabled, the more accurate trig functions from the Windows C runtime are used. See https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/6141957e.8c6be.157053d0e19.Coremail.lh_mouse%40126.com/#msg35353216 and https://mingwpy.github.io/issues.html#math-precision-issues for more details. With changes to compensate for 851cbd2, 861a55d
-os-provides-dlopen and -sb-prelink-linkage-table is incompatible. In order to build a working core with -os-provides-dlopen you must provide the list of all C symbols introduced in make-target-2. With changes to compensate for 851cbd2
git is needed to generate the version file.
the file was renamed at some point and the easiest way to handle the rebase was to put those changes at the end
needed to compensate for db71d58
7729ff3
to
4d2d54c
Compare
these changes prevent obvious compilation errors, however there are a number of changes since 2.2.8 that cause a failure dropping into ldb during compile, this like almost certainly because I missed something when doing the rebase and because there are other compensatory changes that have to be made to the original static linking code
I was able to rebase without compile failures up to 2.2.8 https://github.com/tgbugs/sbcl/tree/static-executable-v2-2.2.8 (though the runtime issue mentioned above is still present). However, beyond 2.2.8 there have been substantial changes made in renaming various functions, in coreparse, and in interaction with immobile space (see e.g. 851cbd2, 8968446, 27e216a, 5a2e639). As a result this branch now hits a memory fault during compilation. @daewok do you have any bandwidth/interest to check in on this? |
I was going to open an issue about my own progress rebasing the static-executable changes to the latest SBCL, but then I saw this PR. My own efforts, done independently of this PR, are available here: https://git.sr.ht/~paulapatience/sbcl. In particular, at least from what I can read from the commit titles here, I've updated the static-executable commits inline rather than adding commits at the end. Like you, I have been able to build up to version 2.2.8 (I started directly at 2.2.6, which contained a change required to build in containers), after which I encountered an issue from 2.2.9 to 2.3.10, and then a different issue from 2.3.11. |
In the end I was able to fix all compilation issues. Of note is that an updated version of asdf-release-ops is required (for those using it), available at https://git.sr.ht/~paulapatience/asdf-release-ops (branch latest-sbcl), for SBCL 2.2.9 and later, because the linkage tables were renamed. Also, starting from 2.3.10, compiling the standalone ldb has to be disabled when compiling with sb-prelink-linkage-table. In 2.3.11, the os_link_from_pointer_table commit becomes unnecessary, but I am not completely certain that my adjustment of the sb-prelink-linkage-table commit is correct. However, I am able to compile and run a statically linked program built with asdf-release-ops for every release from 2.2.6 until 2.4.4, and even until today's latest commit on master. |
There were a few changes that prevented a straight forward rebase, but everything seems to be in order.