ygrek has quit [Remote host closed the connection]
llawrence has joined #picolisp
<llawrence>
Hi, I added another wiki page https://picolisp.com/wiki/?Documentation#runexe It took me a long minute to figure how to split out stderr, but I think the resulting function is quite neat.
llawrence has quit [Quit: Client closed]
llawrence has joined #picolisp
llawrence has quit [Quit: Client closed]
llawrence has joined #picolisp
<abu[7]>
Blitz is "flash". A "Blitzer" fore example is a naked gui running across a soccer field
<abu[7]>
llawrence: The 'err' function is it not?
<abu[7]>
oh, I wanted to write "guy" above :)
<llawrence>
abu: Yes. I found it eventually working through the documentation. Took me a while to determine how to us it. I was thinking I could have another in memory channel. I ended up using it with a tmp file
<abu[7]>
Looks good
<abu[7]>
instead of removing the file in 'finally', you could simply use (tmp ..)
<abu[7]>
(let Err (tmp (rand)) .. (pipe .. Err
<llawrence>
yes. I didn't want them to accumulate so remove it as soon as am done
<abu[7]>
right
<abu[7]>
The problem with 'err' is that it takes only a file arg, not a pipe, so a temp file is needed
<llawrence>
Got it. I've also been fiddling with how to make the external process sticky...keeping the pipe open and the process running until I send an eof.
<abu[7]>
Should be possible
<abu[7]>
(setq *PipeFd (pipe (...)))
<llawrence>
Is that even possible with the pipe pattern or would it have to be more of server process with a socket listener etc
<llawrence>
ah
<abu[7]>
But this may be tricky
<abu[7]>
If data larger than PIPE_BUF are sent
<abu[7]>
Needs a 'task' on the receiving end
<abu[7]>
async
<abu[7]>
But if you just write to the pipe it is OK
<abu[7]>
i.e. the pipe should not print anything, as it is the case in your code
<llawrence>
I have been slow to figure out how to use those difference functions together. It would be useful to keep the external process up, to maintain state if it takes a while to accumulate data to send to it.
<abu[7]>
ok
<llawrence>
I meant ...use the different* functions...
<abu[7]>
yeah, thought so ;)
<llawrence>
The current function works quite well. I was certainly over complicating things in my initial efforts to get it working.
<abu[7]>
👍
llawrence has quit [Quit: Client closed]
<taleon>
I couldn't run `pil +` under OpenBSD until now, because it led to a core dump. Now I have discovered the error. This can be avoided with a special compiler flag. The error occurs from Tiger Lake (11th Gen) on Intel CPUs or newer.
<abu[7]>
Cool, congratulation!
<abu[7]>
Was it an optimizer-flag?
<taleon>
After specifying the left flag `-Wl,-z,nobtcfi`, `pil +` can now also be started without a core dump occurring.
<abu[7]>
hmm, no idea ;)
<taleon>
"Security improvements: o Enable indirect branch tracking (IBT) on amd64 and branch target identification (BTI) on arm64 in both the kernel and in userland. On hardware that supports this feature, it helps enforcing control flow integrity by making sure malicious code cannot jump into the middle of a function."
<abu[7]>
I see
<taleon>
With this left flag you can deactivate BTI.
<abu[7]>
pil does not jump to inside a fun
<abu[7]>
LLVM does not support that
<taleon>
Finally picolisp works under OpenBSD and with the included readline.
<bjorkintosh>
do you need to include readline when rlwrap is available?
<abu[7]>
Isn'r rlwrap rather limited?
<bjorkintosh>
well I also figured, that the prompt is only for a few short interactive sessions.
<bjorkintosh>
majority of the work will be inside a text editor of some sort.
<abu[7]>
eg, TAB completion
<taleon>
I don't know. Probably not, but ctrl+a and ctrl+e work in pil +
<taleon>
tab completion also works
<abu[7]>
TAB should expand symbols according to the current namespaces
<taleon>
ah
<taleon>
Interesting. I'll have to have a look. tab completion the command works though.
<abu[7]>
: (vi 'complete)
<abu[7]>
then 'all*'
<abu[7]>
IIRC rlwrap runs as a separate process
<abu[7]>
Also, I wonder how rlwrap handles signals
<abu[7]>
And in PilBox there is no rlwrap available
<abu[7]>
PilBox opens a pseudo TTY
<abu[7]>
so it needs readline() built-in
<abu[7]>
taleon: ctrl+a and ctrl+e are readline commands? (I use readline in VI mode, to I don't know)
<taleon>
Yes exactly. there is `set -o vi` and `set -o emacs`. Ctrl-a and Ctrl-e are the default values of emacs in the terminal and in readline.
<abu[7]>
ok
<abu[7]>
I have all settings in ~/inputrc
<taleon>
same
<taleon>
Assuming you have identified an application crash caused by ILL_BTCFI, you will need to locate the sections of code with indirect jumps and calls and implement the endbr64 command as a crucial mitigation measure. endbr64, which stands for “ENDBRanch 64-bit”, is a security-enhancing instruction within the x86-64 architecture, utilized by processors adhering to the AMD64 or Intel 64 instruction sets,
<taleon>
which support 64-bit processing.
<taleon>
This command is specifically designed to mark valid targets for indirect jumps and calls—areas frequently targeted in speculative execution attacks such as “Spectre” and “Meltdown”. These attacks take advantage of the processor’s ability to perform speculative execution of instructions to enhance performance, a process that can inadvertently lead to unauthorized data access.
<taleon>
By integrating endbr64 instructions before the points where indirect jumps or calls occur, you can provide the processor with clear indicators of legitimate targets.
<taleon>
I'll have a look in the code and see if I can find an “illegal” jump and then put `endbr64` in front of it. Maybe I will find the problem and can do without the linker flag.
<abu[7]>
Sounds like an LLVM backend issue
<abu[7]>
Pil has a lot of indirect calls though
<abu[7]>
The I/O functions
<taleon>
Hm ok. However, the core dump only occurred with pil +.
<abu[7]>
interesting
<abu[7]>
$Put and $Get are used always
<abu[7]>
(function pointers)
<abu[7]>
eg. (call $Get)
<abu[7]>
So if such a pointer is wrong ...
<abu[7]>
But normally it isn't :)
<taleon>
It does not mean that the jump is wrong, it only means that it is not clear for BTI and IBT and therefore the program is terminated with an error message.
<abu[7]>
I understood it as that it jumps into the middle of a function, giving an illegal instruction
<abu[7]>
Another argument, btw, against rlwrap is that Pil needs to manipulate its "raw" vs, "cooked" state
<bjorkintosh>
ah.
<bjorkintosh>
there's a method behind the logic
ygrek has joined #picolisp
llawrence has joined #picolisp
ygrek has quit [Remote host closed the connection]