Skip to content
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

pod/perlguts pod/perlhacktips - various updates and new content #22881

Open
wants to merge 1 commit into
base: blead
Choose a base branch
from

Conversation

bulk88
Copy link
Contributor

@bulk88 bulk88 commented Jan 1, 2025

See commit.


  • This set of changes does not require a perldelta entry.

Comment on lines +123 to +126
For 5.21.6 and up, to avoid recompiling XS, if you want to add a new interpreter
global variable while hacking on the interpreter, is to rename, repurpose, or
make into union, a current variable from F<intrpvar.h> without change its size,
alignment, and offset.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preferably we'd fix this bug in the XS handshake, so that maint can add new members to the end of the interpreter structure.

Copy link
Contributor Author

@bulk88 bulk88 Jan 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would need 2 numbers/consts then, a fictional "ABI" my_perl struct that is frozen-ish, and the runtime my_perl struct has its normal CC length. But if == changes to >=, it won't detect interp fields like

https://github.com/Perl/perl5/blob/blead/intrpvar.h#L277

https://github.com/Perl/perl5/blob/blead/intrpvar.h#L520 (32b time_t vs 64b , windows mingw gcc hot mess 10-15 years ago)

https://github.com/Perl/perl5/blob/3a16cb5fb8114b7773a9c488c78684bffd787b62/intrpvar.h#L749C28-L749C37

big multi member struct, spec says the type has UB contents, and UB size (OS vendors choice)

https://codebrowser.dev/glibc/glibc/locale/bits/types/__locale_t.h.html#__locale_struct

pre-xs handshake segv, compiler upgrade, made glibc.so and std C disk .h not agree anymore, and segv the persons newer xs modules, but not his interp or old .so XS bin

https://bugzilla.redhat.com/show_bug.cgi?id=1064271#c34

Also it might be time for XS handshake and your new reverse version of it (I can crash the sample if perl.dll and host exe dont agree on the my_perl struct), to pass a better file name than FILE or, allow a trapable fatal error.

A very very tiny API, would be needed to throw a "portable" die to root interp from an accidental 2nd interp/2nd libperl, or from the BOOT: XSUB of the broken 3rd party XS .so/.dll to root interp.

void arg2->cantAttach(void);

setjmp buffers and libc's internals of longjmp() have an above average risk of SEGVing. Remember Win32/64's eternal problem of multiple CRT DLLs in 1 proc. (5.41.8 has it right now, ws2_32.dll links against msvcrt.dll instead of linking against ntdll.dll for libc basics). A tiny api like, or just rename the XS___Module__bootstrap to XS___Module__bootstrap_v4108_A1F0 and move the handshake key into the symbol table of the .so/.dll.

My wishlist has an idea to remove the 1 fn/sym big WinOS .dll XS export table completely from XS. Just have dynaloder call DllMain with DWORD fdwReason *(U32)"PERL".

Debugging XS handshake, its harder than average, either you write code to print the offsets of all fields, and text diff that, or make a .i format it, cut out the interp struct, text diff it. Its most often for me, a Inline::C/EU::MM, -DFLAGS CCFLAGS problems. Even more sinister, last time I did the text diff both interp structs had the same line count!!!! It was a U16 U64 problem, and both aligned (hole) to 64b, so even XS handshake didn't catch that. interp structs were the same total size after standard C integer type alignment.

I will change that area of text to say the correct/intended design is adding members to bottom in maint, but current its not possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants