Nicer way of interacting with upcalls?

[Quân Anh Mai]

Hi,

That does not sound possible. The fundamental reason is that a function
is profoundly different from a piece of data. A function is an executable,
the code segments are marked as read-execute while the data segments are
marked as read-write. These 2 are mutually exclusive, so you cannot
allocate some code at the same place as other kinds of data. This also
means that you have to separate between assembling and executing a code
segment as between those there must be a syscall to change permissions of
that code segment.

This of course only means that you cannot achieve what you want in a
straightforward manner. Since foreign API is so powerful a beast you can do
every kind of horrible thing such as manually chasing a function pointer,
disassembling that upcall stub, reassembling back at anywhere you want and
finally marking the region as executable :-)

Regards,
Quan Anh

On Mon, 24 Jan 2022 at 22:54, Mark Hammons <markehammons at gmail.com> wrote:

> Hi Panama development team!
>
> Recently, I released v0.1.0 of my library Slinc(
> https://mhammons.gitlab.io/slinc/blog/2021/01/22/V0-1-0-Released.html),
> and
> so far using the foreign interface has been great. However, there's one
> incongruity that really bugged me. Upcalls do not behave like other types
> in foreign. For all the other types that can be passed to C, I've been able
> to separate allocation of native space and writing data to native space.
> The process to create an upcall does both at once though, which makes it
> weird compared to other types (for example, can't replace an upcall without
> copying (at least temporarily) the new upcall to an unrelated address. Is
> there any way this could be rectified?
>
> To be clear, I'd like two things if it's possible to add them: 1. a method
> or memory layout that can take a function descriptor and let me know the
> byte size needed to store 2. a method in MemoryAccess for writing a method
> handle (or maybe have upcall take a memory address/segment that it write
> stuff to).
>
> If I had these two things, function pointers in my library would not be a
> special case anymore.
>
> Thanks in advance for the great addition to the java standard library,
> looking forward to the improvements in java 18!
>
> ~Mark Hammons
>