From Newsgroup: comp.arch

Waldek Hebisch <antispam@fricas.org> schrieb:

- one could create trampolines in a separate area of memory. In
such case there is trouble with dealocating no longer needed
trampolines. This trouble can be resolved by using GC. Or
by using a parallel stack dedicated to trampolines.

[...]

gcc has -ftrampoline-impl=[stack|heap], see https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

Don't longjmp out of a nested function though.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Thomas Koenig <tkoenig@netcologne.de> posted:

Waldek Hebisch <antispam@fricas.org> schrieb:

- one could create trampolines in a separate area of memory. In
such case there is trouble with dealocating no longer needed
trampolines. This trouble can be resolved by using GC. Or
by using a parallel stack dedicated to trampolines.

[...]

gcc has -ftrampoline-impl=[stack|heap], see https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

Don't longjmp out of a nested function though.

Or longjump around subroutines using 'new'.
Or longjump out of 'signal' handlers.
...

Somebody should write a paper entitled "longjump considered dangerous" annotating all the way it can be used to abuse compiler assumptions.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup <user5857@newsgrouper.org.invalid> writes:

Thomas Koenig <tkoenig@netcologne.de> posted:

Waldek Hebisch <antispam@fricas.org> schrieb:

- one could create trampolines in a separate area of memory. In
such case there is trouble with dealocating no longer needed
trampolines. This trouble can be resolved by using GC. Or
by using a parallel stack dedicated to trampolines.

[...]

gcc has -ftrampoline-impl=[stack|heap], see
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

Don't longjmp out of a nested function though.

Or longjump around subroutines using 'new'.

Actually, one must take care when calling longjmp
from a function that allocates memory to ensure that
the memory will be tracked and/or deallocated as
and when required. That's perfectly feasible.

Although in my experience, code that uses longjmp
(say instead of C++ exceptions) is performance
sensitive and performance sensitive code doesn't
do dynamic allocation (i.e. high-performance
C++ code won't use the standard C++ library
functionality that requires dynamic allocation).

Or longjump out of 'signal' handlers.

Again, one must take the appropriate care. Such as
using the correct API (e.g. POSIX siglongjmp(2)).

It is quite common to use siglongjmp to leave
a SIGINT (Control-C) handler.

https://pubs.opengroup.org/onlinepubs/9799919799/functions/siglongjmp.html
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

scott@slp53.sl.home (Scott Lurndal) writes:

MitchAlsup <user5857@newsgrouper.org.invalid> writes:

Or longjump out of 'signal' handlers.

Again, one must take the appropriate care. Such as
using the correct API (e.g. POSIX siglongjmp(2)).

The restrictions on siglongjmp() when jumping out of signal handlers
are the same as for longjmp(). See the section "Application Usage" in https://pubs.opengroup.org/onlinepubs/9799919799/functions/longjmp.html

The only difference is that sigsetjmp() saves the signal mask and
siglongjmp() restores it.

It is quite common to use siglongjmp to leave
a SIGINT (Control-C) handler.

In Gforth we certainly use longjmp() to leave the SIGINT handler as
well as a number of synchronous-signal handlers in Gforth (Gforth does
nothing with signal masks, so sigsetjmp()/siglongjmp() would make no difference). Of course, there is the possibility that the signal
handler is invoked while some internal structure of an
async-signal-unsafe function such as malloc() or fwrite() is in an
inconsistent state, and then we will see breakage, but I have not seen
that yet, and nobody has complained.

The safe approach would be to set a flag in the SIGINT handler, and
check that flag in safe places, but relatively frequently (e.g., just
before a loop-back edge in the Forth program).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

scott@slp53.sl.home (Scott Lurndal) writes:

MitchAlsup <user5857@newsgrouper.org.invalid> writes:

Or longjump out of 'signal' handlers.

Again, one must take the appropriate care. Such as
using the correct API (e.g. POSIX siglongjmp(2)).

The restrictions on siglongjmp() when jumping out of signal handlers
are the same as for longjmp(). See the section "Application Usage" in >https://pubs.opengroup.org/onlinepubs/9799919799/functions/longjmp.html

The only difference is that sigsetjmp() saves the signal mask and >siglongjmp() restores it.

Which is important in any threaded application that uses
signals.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 31.08.2025 16:43 Uhr Stefan Monnier wrote:

Same here (tho I was on team Debian), but I don't think GNU/Linux
enthusiasts were the main buyers of those Opteron and
Athlon64 machines.

Athlon 64 machines were mostly shipped with Windows XP 32 bit - even
when XP 64 bit existed for that architecture.
--
kind regards
Marco

Send spam to 1756651406muell@stinkedores.dorfdsl.de

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 2025-09-21, Marco Moock wrote:

On 31.08.2025 16:43 Uhr Stefan Monnier wrote:

Same here (tho I was on team Debian), but I don't think GNU/Linux
enthusiasts were the main buyers of those Opteron and
Athlon64 machines.

Athlon 64 machines were mostly shipped with Windows XP 32 bit - even
when XP 64 bit existed for that architecture.

Which one was NT 5.2 and not 5.1? XP for IA-64 or XP for amd64?
--
Nuno Silva
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 21 Sep 2025 15:45:52 +0100
Nuno Silva <nunojsilva@invalid.invalid> wrote:

On 2025-09-21, Marco Moock wrote:

On 31.08.2025 16:43 Uhr Stefan Monnier wrote:

Same here (tho I was on team Debian), but I don't think GNU/Linux
enthusiasts were the main buyers of those Opteron and
Athlon64 machines.

Athlon 64 machines were mostly shipped with Windows XP 32 bit - even
when XP 64 bit existed for that architecture.

Which one was NT 5.2 and not 5.1? XP for IA-64 or XP for amd64?

XP for AMD64. The same version number as WS2003 https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions


--- Synchronet 3.21a-Linux NewsLink 1.2