can we quit patching quickjs?

can we quit patching quickjs?

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

Folks, I had a clever, and somewhat frightening, and somewhat ugly thought, but no uglier that patching and building quickjs ourselves.
I can enqueue a job manually, just as promise does, then scan the runtime structure to see what has changed.
This is, hopefully, the location of the jobs queue.
The commit is 42d5b695989a9dc92dc66a7de6f92176d2e0a0de
Look at it as a patch file and see what I did.
I encourage you brave souls to try it out.
If we all decide it works, and is safe, then we can delete tools/quickjobfixup, and remove all  those instructions about patching and building quick from source,
and just link to the quick package, if one is distributed and available.
Of course if there is no quick package, and there often isn't, the user or the package manager can still build quick from source, but he doesn't have to patch it.

I don't know why I didn't think of this sooner.

Comments welcome.

Karl Dahlke

Re: can we quit patching quickjs?

[Dominique Martinet]

Karl Dahlke wrote on Tue, Aug 16, 2022 at 07:40:49PM -0400:
> Folks, I had a clever, and somewhat frightening, and somewhat ugly
> thought, but no uglier that patching and building quickjs ourselves.
> I can enqueue a job manually, just as promise does, then scan the
> runtime structure to see what has changed.
> This is, hopefully, the location of the jobs queue.

Hm, I had quickjs "2020-11-08 release take 2" and the offset for me was
280, so a bit off the mark from the 64-256 range.
With current quickjs master it moved to 288, I'm not sure what's
different with you.

The code does get the right offset though, we can also just extract the
offset from libquickjs.a if we build it ourselves as the default build
will have -g (packages will often strip debug infos, so we lose that
possibility if there ever is a package...)

$ pahole -y JSRuntime libquickjs.a | grep job_list
	struct list_head           job_list;             /*   288    16 */

(which says it's offset 288 alright)



With that said, I can't say I like it but JS_EnqueueJob only changes the
job_list in that struct so it should be safe enough with a slightly
larger range...?


I didn't follow as closely as I should have, reading the comments it
looks like we need this because we share the same js context between
sessions and don't want to run timers in the background, right?
I recall this was done to share the common startwindow code, because
it's a bit slow to setup for every session?

I remember trying to play around precompiling it so we'd just need to
copy a blob for new inits, but I don't remember how that ended; at some
point we might just as well give up on mucking around with quickjs
internals and allocate a context par session if possible...

--
Dominique

can we quit patching quickjs?

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

Perhaps your build is 64-bit machine, with 8-byte pointers instead of 4-byte pointers.
I can't see any other way that location would push out so far.
I could change the range to 400.
I don't want to make it too high or I could be trolling on invalid memory.
Remember, I don't know the size of the struct.
It is opaque in every way.

I'm not counting on a debug symbol to do this, just the global variables that have to be there for anyone to link against the quick library.

Karl Dahlke