ingle -> single #1
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 ",".
Move the linkage table filling for shrinkwrapped executables into its own function.
Patch originally by Manuel Giraud <[email protected]>, I just cleaned up some comments.
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.
-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.
daewok
force-pushed
the
static-executable-v2
branch
from
13032a9 to
20f2a97
Compare
daewok
force-pushed
the
static-executable-v2
branch
from
20f2a97 to
f6f8e19
Compare
daewok
pushed a commit
that referenced
this pull request
Aug 31, 2021
The cases which zeroize the result due to oversized constant shift should not care where the input operand is. Also, zeroize will accepts stack TNs. So remember rule #1 of writing a :LOAD-IF, namely: it's always wrong.
daewok
force-pushed
the
static-executable-v2
branch
from
f6f8e19 to
52f4fa7
Compare
daewok
force-pushed
the
static-executable-v2
branch
from
52f4fa7 to
bde302a
Compare
daewok
force-pushed
the
static-executable-v2
branch
from
453fd67 to
b984fc9
Compare
daewok
force-pushed
the
static-executable-v2
branch
from
b984fc9 to
d5d3197
Compare
daewok
force-pushed
the
static-executable-v2
branch
from
d5d3197 to
cf15118
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.