Re: Emacs-devel Digest, Vol 246, Issue 17

Re: Emacs-devel Digest, Vol 246, Issue 17

[ali_gnu2]

On 8/17/24 10:00 AM, emacs-devel-request@gnu.org wrote:
>> Moreover, whatever becomes of the portable ELF unexec should
>> not affect the Solaris unexec, which is provided by the operating system
>> and should function without the likes of gmalloc.
> AFAIK, the portable dumper is the default also on Solaris, so there is
> no need to keep the unexec build around just for that platform.

    The Solaris code that does that is called dldump() and was
invented years ago (~25 years?) to support emacs. We used to
get occasional bug reports about emacs not dumping from time
to time, and dldump() put an end to that.

I'm the person who maintains that code in Solaris, and also the
person who packages Emacs for our platform. We stopped using the
unexec code the moment the portable dumper arrived, and haven't
looked back. I don't think we'd even notice if unexec() went away.

There are open source variants of Solaris for whom I don't
speak, but from what I know about our common code, they should
not be any more stuck on unexec() than we are. pdumper really
doesn't use any unix features that didn't exist decades ago.

Thanks for caring, but don't let us slow this down. The portable
dumper is The Way.

- Ali

Re: Emacs-devel Digest, Vol 246, Issue 17

[Po Lu]

ali_gnu2@emvision.com writes:

>    The Solaris code that does that is called dldump() and was
> invented years ago (~25 years?) to support emacs. We used to
> get occasional bug reports about emacs not dumping from time
> to time, and dldump() put an end to that.
>
> I'm the person who maintains that code in Solaris, and also the
> person who packages Emacs for our platform. We stopped using the
> unexec code the moment the portable dumper arrived, and haven't
> looked back. I don't think we'd even notice if unexec() went away.
>
> Thanks for caring, but don't let us slow this down. The portable
> dumper is The Way.
>
> - Ali

Hello Ali!

I think you underestimate the number of programs using dldump.  I've
seen both Perl 5 and GNU Make hacked to save state with dldump, on
Oracle Solaris, producing binaries that don't depend on the presence of
a state file and probably start faster as well.  Meanwhile
pdumper-dumped binaries appear to crash in an x86 Solaris 10 zone,
though I don't really use this configuration and I'm not interested in
trying the portable dumper on sparc:

core 'core' of 7021:        ../../src/bootstrap-emacs -batch --no-site-file --no-site-lisp -f batc
 00007fffaf433dc2 ???????? ()
 00007fffaf5eb3d7 ???????? ()
 00007fffaf5ec590 ???????? ()
 00007fffae3f351a _lwp_kill () + a
 00007fffae3981b9 raise () + 19
 00000000008baf90 terminate_due_to_signal () + c0
 000000000090236e ???????? ()
 0000000000902334 deliver_thread_signal () + 74
 00000000009023b0 deliver_fatal_thread_signal () + 10
 00000000009024ef handle_sigsegv () + 4f
 00007fffae3edd16 __sighndlr () + 6
 00007fffae3e25e2 call_user_handler () + 252
 00007fffae3e280e sigacthandler () + ee
 00007fffaf5ea82d ???????? ()
 ffffffffffffffff ???????? ()
 00000000009c77e7 lisp_align_malloc () + 4d7
 00000000009c9dd2 make_float () + 42
 00000000009d2e9d init_alloc () + d
 00000000008bd373 main () + bb3
 00000000006d15ab ???????? ()

> There are open source variants of Solaris for whom I don't
> speak, but from what I know about our common code, they should
> not be any more stuck on unexec() than we are. pdumper really
> doesn't use any unix features that didn't exist decades ago.

I don't believe we try to support Illumos.  If Emacs should work, more
power to them, but they have bigger fish to fry when GCC exception
handling fails if an exception is raised the instant an object is
unmapped, prompting dl_iterate_phdr to return -1.

Re: Emacs-devel Digest, Vol 246, Issue 17

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> I don't believe we try to support Illumos.  If Emacs should work, more
> power to them, but they have bigger fish to fry when GCC exception
> handling fails if an exception is raised the instant an object is
> unmapped, prompting dl_iterate_phdr to return -1.

As when an iconv_t is closed while an exception is raised in another
thread.

Solaris dldump (was: Pure space)

[ali_gnu2]

On 8/17/24 6:10 PM, Po Lu wrote:
> Hello Ali!
> 
> I think you underestimate the number of programs using dldump.  I've
> seen both Perl 5 and GNU Make hacked to save state with dldump, on
> Oracle Solaris, producing binaries that don't depend on the presence of
> a state file and probably start faster as well.  Meanwhile
> pdumper-dumped binaries appear to crash in an x86 Solaris 10 zone,
> though I don't really use this configuration and I'm not interested in
> trying the portable dumper on sparc:
> 
> core 'core' of 7021:        ../../src/bootstrap-emacs -batch --no-site-file --no-site-lisp -f batc
>   00007fffaf433dc2 ???????? ()
>   00007fffaf5eb3d7 ???????? ()
>   00007fffaf5ec590 ???????? ()
>   00007fffae3f351a _lwp_kill () + a
>   00007fffae3981b9 raise () + 19
>   00000000008baf90 terminate_due_to_signal () + c0
>   000000000090236e ???????? ()
>   0000000000902334 deliver_thread_signal () + 74
>   00000000009023b0 deliver_fatal_thread_signal () + 10
>   00000000009024ef handle_sigsegv () + 4f
>   00007fffae3edd16 __sighndlr () + 6
>   00007fffae3e25e2 call_user_handler () + 252
>   00007fffae3e280e sigacthandler () + ee
>   00007fffaf5ea82d ???????? ()
>   ffffffffffffffff ???????? ()
>   00000000009c77e7 lisp_align_malloc () + 4d7
>   00000000009c9dd2 make_float () + 42
>   00000000009d2e9d init_alloc () + d
>   00000000008bd373 main () + bb3
>   00000000006d15ab ???????? ()
> 

Hello!

    Is that stack from the s10 zone?

You're probably right that I don't know who is using
dldump(), outside of emacs, but not to worry, it's not
going away. It's a committed interface, so hard to remove,
and at the same time, isn't causing any problems. Nonetheless,
it's not our favored way to deploy emacs, and I wouldn't want
anyone to think we prefer its use, or require it.

We use pdumper on newer Solaris 11.4, both x86 and sparc,
with no reported issues. I wasn't aware of the Solaris 10
zone problems (haven't seen any reports). If you end up
looking at it, and think that the s10 zone is somehow at
fault, please feel free to contact me offline. However,
given that s10 is 20 years old, it wouldn't be unreasonable
to drop it off the support tail. From discussions with Rainer
Orth, who maintains gcc for Solaris, I believe that s10 support
for gcc has ended, or is very close to ending. My personal
opinion is that anyone happy to use a 20 year old OS should
have no problem using an older gcc, or emacs, so it's not
really the end of the road for those folks.

>> There are open source variants of Solaris for whom I don't
>> speak, but from what I know about our common code, they should
>> not be any more stuck on unexec() than we are. pdumper really
>> doesn't use any unix features that didn't exist decades ago.
> 
> I don't believe we try to support Illumos.  If Emacs should work, more
> power to them, but they have bigger fish to fry when GCC exception
> handling fails if an exception is raised the instant an object is
> unmapped, prompting dl_iterate_phdr to return -1.

I expect that we're both benefiting from your work anyway.
Isn't emacs still largely C (not C++)? I wouldn't expect
exception handling to be needed, so maybe it's OK.

I do know that dl_iterate_phdr() is a relatively recent
addition for us, and was done after the split, so that
is a case where the code is not common. No doubt the fix
for Illumos would not be difficult, if/when they get to it.

Thanks!

- Ali

Re: Solaris dldump

[Po Lu]

ali_gnu2@emvision.com writes:

> On 8/17/24 6:10 PM, Po Lu wrote:
>> Hello Ali!
>> I think you underestimate the number of programs using dldump.  I've
>> seen both Perl 5 and GNU Make hacked to save state with dldump, on
>> Oracle Solaris, producing binaries that don't depend on the presence of
>> a state file and probably start faster as well.  Meanwhile
>> pdumper-dumped binaries appear to crash in an x86 Solaris 10 zone,
>> though I don't really use this configuration and I'm not interested in
>> trying the portable dumper on sparc:
>> core 'core' of 7021:        ../../src/bootstrap-emacs -batch
>> --no-site-file --no-site-lisp -f batc
>>   00007fffaf433dc2 ???????? ()
>>   00007fffaf5eb3d7 ???????? ()
>>   00007fffaf5ec590 ???????? ()
>>   00007fffae3f351a _lwp_kill () + a
>>   00007fffae3981b9 raise () + 19
>>   00000000008baf90 terminate_due_to_signal () + c0
>>   000000000090236e ???????? ()
>>   0000000000902334 deliver_thread_signal () + 74
>>   00000000009023b0 deliver_fatal_thread_signal () + 10
>>   00000000009024ef handle_sigsegv () + 4f
>>   00007fffae3edd16 __sighndlr () + 6
>>   00007fffae3e25e2 call_user_handler () + 252
>>   00007fffae3e280e sigacthandler () + ee
>>   00007fffaf5ea82d ???????? ()
>>   ffffffffffffffff ???????? ()
>>   00000000009c77e7 lisp_align_malloc () + 4d7
>>   00000000009c9dd2 make_float () + 42
>>   00000000009d2e9d init_alloc () + d
>>   00000000008bd373 main () + bb3
>>   00000000006d15ab ???????? ()
>> 
>
> Hello!
>
>    Is that stack from the s10 zone?

Yes.

> You're probably right that I don't know who is using
> dldump(), outside of emacs, but not to worry, it's not
> going away. It's a committed interface, so hard to remove,
> and at the same time, isn't causing any problems. Nonetheless,
> it's not our favored way to deploy emacs, and I wouldn't want
> anyone to think we prefer its use, or require it.
>
> We use pdumper on newer Solaris 11.4, both x86 and sparc,
> with no reported issues. I wasn't aware of the Solaris 10
> zone problems (haven't seen any reports). If you end up
> looking at it

I plan to, but not till Emacs 30 is released.

> and think that the s10 zone is somehow at fault, please feel free to
> contact me offline. However, given that s10 is 20 years old, it
> wouldn't be unreasonable to drop it off the support tail. From
> discussions with Rainer Orth, who maintains gcc for Solaris, I believe
> that s10 support for gcc has ended, or is very close to ending. My
> personal opinion is that anyone happy to use a 20 year old OS should
> have no problem using an older gcc, or emacs, so it's not really the
> end of the road for those folks.

I'm fine with using an older C compiler (whether GCC or no), but we have
plenty of precedent in these quarters for remaining on decades-old
operating systems.  Not least when the operating system is to be
supported for two more years.

> I expect that we're both benefiting from your work anyway.
> Isn't emacs still largely C (not C++)? I wouldn't expect
> exception handling to be needed, so maybe it's OK.

C, but several libraries draw in C++ dependencies and others create
threads: HarfBuzz and librsvg for example.

Re: Solaris dldump

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> ali_gnu2@emvision.com writes:
>
>> [...] However, given that s10 is 20 years old, it
>> wouldn't be unreasonable to drop it off the support tail. From
>> discussions with Rainer Orth, who maintains gcc for Solaris, I believe
>> that s10 support for gcc has ended, or is very close to ending. My
>> personal opinion is that anyone happy to use a 20 year old OS should
>> have no problem using an older gcc, or emacs, so it's not really the
>> end of the road for those folks.

Thank you for sharing your informed opinion.  I also can't see why we
should consider the 20 year old Solaris 10 a blocker for removing the
unexec build in Emacs 31.

For example, even according to current Oracle communications, it will
reach EOL in around two years.  This means that by the time we release
Emacs 31, users will already be busy moving to Solaris 11.  If they
aren't, they're fine on Emacs 30, or they can help us fix pdumper.

> I'm fine with using an older C compiler (whether GCC or no), but we have
> plenty of precedent in these quarters for remaining on decades-old
> operating systems.  Not least when the operating system is to be
> supported for two more years.

If there is interest in that very old proprietary system, and there is
some problem with using pdumper there, then users should report bugs and
volunteers should step up to fix them.

Re: Solaris dldump

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Thank you for sharing your informed opinion.  I also can't see why we
> should consider the 20 year old Solaris 10 a blocker for removing the
> unexec build in Emacs 31.
>
> For example, even according to current Oracle communications, it will
> reach EOL in around two years.

"Even" implies that it will reach EOL sooner, but by all indications the
EOL date will be as stated, if it is not postponed any further, and
Oracle and related organizations will continue to support the operating
system at a reduced intensity indefinitely.  Why do you suppose this is,
if otherwise than because the operating system is abundantly used?

Fedora 40's remaining support period is shorter; should we not cease to
support it any longer, in view of the one or two crashes in the PGTK
configuration that can only be reproduced with the distribution
packages, and which continue to languish on the bug tracker?

> This means that by the time we release Emacs 31, users will already be
> busy moving to Solaris 11

This is nonsense.  It's impossible to upgrade installed Solaris 10
systems to Solaris 11, and being a robust system many users are content
to remain there till hell freezes over.  

> If they aren't, they're fine on Emacs 30, or they can help us fix
> pdumper.

No one is ever "fine on" an outdated text editor.  You agree that this
principle applies to operating systems, but when Emacs is in question,
the about-face comes very quickly.

It's a waste of my time (and my organization's) that would be totally
needless if you were not so trigger-happy with old and proven features.
It's a-ok to retain pure space to avoid burdening someone with very
hypothetical additional labor, but it's not possible to take a far less
radical measure to conserve my time.  In any event, I promised to devote
some of it to this issue after Emacs 30 is released.

> If there is interest in that very old proprietary system, and there is
> some problem with using pdumper there, then users should report bugs and
> volunteers should step up to fix them.

According to Microsoft, Windows XP reached EOL in 2014, and yet its
users are none the less inclined to the latest releases of Emacs (nor
has it been prevented from retaining 0.38% of Windows's aggregate market
share, in excess of Windows 8's 0.24):

  https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide.

Re: Solaris dldump

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: ali_gnu2@emvision.com,  emacs-devel@gnu.org
> Date: Mon, 19 Aug 2024 07:56:13 +0800
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > Thank you for sharing your informed opinion.  I also can't see why we
> > should consider the 20 year old Solaris 10 a blocker for removing the
> > unexec build in Emacs 31.
> >
> > For example, even according to current Oracle communications, it will
> > reach EOL in around two years.
> 
> "Even" implies that it will reach EOL sooner, but by all indications the
> EOL date will be as stated, if it is not postponed any further, and
> Oracle and related organizations will continue to support the operating
> system at a reduced intensity indefinitely.  Why do you suppose this is,
> if otherwise than because the operating system is abundantly used?
> 
> Fedora 40's remaining support period is shorter; should we not cease to
> support it any longer, in view of the one or two crashes in the PGTK
> configuration that can only be reproduced with the distribution
> packages, and which continue to languish on the bug tracker?

These aspects are almost unrelated to the issue at hand: we don't make
our decisions of dropping support of some platform or feature because
it is EOLed by its vendor or developers.  Instead, we make our own
decisions, and in general try not to drop any feature/platform if we
don't have to.

In this case, keeping the support of unexec longer becomes a
maintenance burden (just look at the #ifdef mess it requires), and
that is the reason why we think we should drop those platforms that
don't currently support pdumper.  The fact that all those platforms
are either very old or have better alternatives is just a supporting
consideration, not the main reason.

> It's a waste of my time (and my organization's) that would be totally
> needless if you were not so trigger-happy with old and proven features.

We are very far from being "trigger-happy" in these matters.  In fact,
we are often accused in the opposite.  E.g., Gnulib dropped support
for some of these platforms long ago, and couldn't be convinced to
reconsider, even when told that Emacs needs that continued support.

So what you say above is completely uncalled-for and unfair.

> It's a-ok to retain pure space to avoid burdening someone with very
> hypothetical additional labor, but it's not possible to take a far less
> radical measure to conserve my time.  In any event, I promised to devote
> some of it to this issue after Emacs 30 is released.

If you intend to work on modifying the unexec code to not use pure
space, don't waste your time: I will object to any serious development
of the unexec code.  The only way forward for the platforms that
currently need unexec is to start using pdumper.

> > If there is interest in that very old proprietary system, and there is
> > some problem with using pdumper there, then users should report bugs and
> > volunteers should step up to fix them.
> 
> According to Microsoft, Windows XP reached EOL in 2014, and yet its
> users are none the less inclined to the latest releases of Emacs (nor
> has it been prevented from retaining 0.38% of Windows's aggregate market
> share, in excess of Windows 8's 0.24):
> 
>   https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide.

Once again, it is immaterial when a platform was EOLed.  That is not
the reason why we want to drop unexec.

Re: Solaris dldump

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> In this case, keeping the support of unexec longer becomes a
> maintenance burden (just look at the #ifdef mess it requires), and
> that is the reason why we think we should drop those platforms that
> don't currently support pdumper.  The fact that all those platforms
> are either very old or have better alternatives is just a supporting
> consideration, not the main reason.

You mean the 35 instances of "HAVE_UNEXEC" in C source files, not
excepting the "HAVE_PDUMPER || HAVE_UNEXEC" conditions, or the malloc
and Gnulib flags that aren't necessary on unexsol?  I would be as glad
as you to see most of them removed, as they are not significant on the
systems where unexec should be retained.

> If you intend to work on modifying the unexec code to not use pure
> space, don't waste your time: I will object to any serious development
> of the unexec code.  The only way forward for the platforms that
> currently need unexec is to start using pdumper.

I need not modify the unexec code, or adapt it to configurations without
pure space, as there simply is no code to adapt.  unexsol.c works _now_
with or without pure space, and I would be immensely surprised if the
same were not true of DJGPP, and as it happens, whether in Emacs or
elsewhere.

> Once again, it is immaterial when a platform was EOLed.  That is not
> the reason why we want to drop unexec.

That's not what I heard just one message removed from mine, where being
two years from EOL was stated to be sufficient grounds to withdraw
support.

Re: Solaris dldump

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  ali_gnu2@emvision.com,  emacs-devel@gnu.org
> Date: Mon, 19 Aug 2024 20:09:36 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > In this case, keeping the support of unexec longer becomes a
> > maintenance burden (just look at the #ifdef mess it requires), and
> > that is the reason why we think we should drop those platforms that
> > don't currently support pdumper.  The fact that all those platforms
> > are either very old or have better alternatives is just a supporting
> > consideration, not the main reason.
> 
> You mean the 35 instances of "HAVE_UNEXEC" in C source files, not
> excepting the "HAVE_PDUMPER || HAVE_UNEXEC" conditions, or the malloc
> and Gnulib flags that aren't necessary on unexsol?

I mean all of them, and I also mean the need to understand the fine
details of unexec, the differences between it and pdumper mode, and
the reason for some tricky code we need for unexec.  Most of current
frequent contributors to Emacs have no idea about that, and thus the
unexec build is very easy to break by some change that doesn't take it
into account.

> I would be as glad as you to see most of them removed, as they are
> not significant on the systems where unexec should be retained.

They are necessary.

> > Once again, it is immaterial when a platform was EOLed.  That is not
> > the reason why we want to drop unexec.
> 
> That's not what I heard just one message removed from mine

You've misunderstood what Stefan meant.  He was just responding to
your message, nothing more nothing less.

Re: Solaris dldump

[Pip Cet]

"Po Lu" <luangruo@yahoo.com> writes:

> It's a-ok to retain pure space to avoid burdening someone with very
> hypothetical additional labor

Wait, I'm not sure I understand that part.  How does removing pure space
burden anyone with additional labor, hypothetical or not?

Also, do the systems that don't support pdumper but do support unexec
work without dumping, when running temacs directly? It takes very long
to build Emacs that way, but since we're talking non-free operating
systems it might be acceptable to ask people to cross-compile for now,
kind of like we do for the Android builds where the .elc files are
generated on the build systems.

Pip

Re: Solaris dldump

[Po Lu]

Pip Cet <pipcet@protonmail.com> writes:

> Wait, I'm not sure I understand that part.  How does removing pure space
> burden anyone with additional labor, hypothetical or not?

Isn't this theoretical burden the reason that pure space is not to be
removed except along with unexec?

> Also, do the systems that don't support pdumper but do support unexec
> work without dumping, when running temacs directly? It takes very long
> to build Emacs that way, but since we're talking non-free operating
> systems it might be acceptable to ask people to cross-compile for now,
> kind of like we do for the Android builds where the .elc files are
> generated on the build systems.

There is a substantial segment of our users who don't expect Emacs to
start in 5+ seconds, if only judging by the hullabaloo that erupts
whenever startup performance is threatened or even mildly retarded.
Even in the Android port, this penalty is paid once on installation and
a dump file is retained for subsequent initializations of the same
binary.

Anyway, I want pure space gone as much as any of us, I just don't agree
that taking unexec down with it is justified.  Maybe the ELF, XCOFF, and
Windows unexecs, but not the Solaris or DOS ones.

Re: Solaris dldump

[Pip Cet]

"Po Lu" <luangruo@yahoo.com> writes:
> Pip Cet <pipcet@protonmail.com> writes:
>> Wait, I'm not sure I understand that part.  How does removing pure space
>> burden anyone with additional labor, hypothetical or not?
>
> Isn't this theoretical burden the reason that pure space is not to be
> removed except along with unexec?

Maybe a compromise would be to keep unexec but put it on probation,
promising to remove it if problems arise that cannot be convincingly and
immediately fixed?

>> Also, do the systems that don't support pdumper but do support unexec
>> work without dumping, when running temacs directly? It takes very long
>> to build Emacs that way, but since we're talking non-free operating
>> systems it might be acceptable to ask people to cross-compile for now,
>> kind of like we do for the Android builds where the .elc files are
>> generated on the build systems.
>
> There is a substantial segment of our users who don't expect Emacs to
> start in 5+ seconds, if only judging by the hullabaloo that erupts
> whenever startup performance is threatened or even mildly retarded.

I agree, but I also think some compromise will have to be found.

> Even in the Android port, this penalty is paid once on installation and
> a dump file is retained for subsequent initializations of the same
> binary.

A very clever hack, I must say!

> Anyway, I want pure space gone as much as any of us, I just don't agree
> that taking unexec down with it is justified.  Maybe the ELF, XCOFF, and
> Windows unexecs, but not the Solaris or DOS ones.

DOS in particular is what triggered my question: given the limitations
of DOS systems, it's quite possible temacs-as-emacs just wouldn't fly on
those machines.

Pip

Re: Solaris dldump

[Eli Zaretskii]

> Date: Mon, 19 Aug 2024 12:10:19 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>, ali_gnu2@emvision.com,
>  emacs-devel@gnu.org
> 
> "Po Lu" <luangruo@yahoo.com> writes:
> > Pip Cet <pipcet@protonmail.com> writes:
> >> Wait, I'm not sure I understand that part.  How does removing pure space
> >> burden anyone with additional labor, hypothetical or not?
> >
> > Isn't this theoretical burden the reason that pure space is not to be
> > removed except along with unexec?
> 
> Maybe a compromise would be to keep unexec but put it on probation,
> promising to remove it if problems arise that cannot be convincingly and
> immediately fixed?

That'd just add to code churn and maintenance burden.  So I prefer
removing it to begin with.

> > Anyway, I want pure space gone as much as any of us, I just don't agree
> > that taking unexec down with it is justified.  Maybe the ELF, XCOFF, and
> > Windows unexecs, but not the Solaris or DOS ones.
> 
> DOS in particular is what triggered my question: given the limitations
> of DOS systems, it's quite possible temacs-as-emacs just wouldn't fly on
> those machines.

Those limitations are not relevant in our case.

But this all is besides the point.

Re: Solaris dldump

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Mon, 19 Aug 2024 12:10:19 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Stefan Kangas <stefankangas@gmail.com>, ali_gnu2@emvision.com,
>>  emacs-devel@gnu.org
>>
>> "Po Lu" <luangruo@yahoo.com> writes:
>> > Pip Cet <pipcet@protonmail.com> writes:
>> >> Wait, I'm not sure I understand that part.  How does removing pure space
>> >> burden anyone with additional labor, hypothetical or not?
>> >
>> > Isn't this theoretical burden the reason that pure space is not to be
>> > removed except along with unexec?
>>
>> Maybe a compromise would be to keep unexec but put it on probation,
>> promising to remove it if problems arise that cannot be convincingly and
>> immediately fixed?
>
> That'd just add to code churn and maintenance burden.  So I prefer
> removing it to begin with.

I've just gone through configure.ac removing all the code that depends
on unexec (no doubt I've missed some), and I must say I now agree it is
time for unexec to go.  In particular, it had so far escaped my
attention that it's incompatible with native compilation!

So I'll update the scratch/no-purespace branch to also remove unexec,
and of course I'm offering to help anyone who wants to fix the remaining
non-pdumper ports.

And while I am skeptical of the value of ASLR, it wuold be really
embarrassing to run into a security issue that's exploitable only
because Emacs disables ASLR for unexec builds.

>> > Anyway, I want pure space gone as much as any of us, I just don't agree
>> > that taking unexec down with it is justified.  Maybe the ELF, XCOFF, and
>> > Windows unexecs, but not the Solaris or DOS ones.
>>
>> DOS in particular is what triggered my question: given the limitations
>> of DOS systems, it's quite possible temacs-as-emacs just wouldn't fly on
>> those machines.
>
> Those limitations are not relevant in our case.

I think it's relevant whether DOS will become completely unusable or
merely difficult to use once unexec is removed, and what can be done to
fix it.

Does the DOS port work on free DOS clones?  And is there a way to gain
access to a Solaris machine to fix pdumper on it?

Pip

Re: Solaris dldump

[Eli Zaretskii]

> Date: Mon, 19 Aug 2024 13:46:11 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: luangruo@yahoo.com, stefankangas@gmail.com, ali_gnu2@emvision.com, emacs-devel@gnu.org
> 
> I've just gone through configure.ac removing all the code that depends
> on unexec (no doubt I've missed some), and I must say I now agree it is
> time for unexec to go.  In particular, it had so far escaped my
> attention that it's incompatible with native compilation!

All the major new feature don't support unexec; native-compilation was
just the first.

> And while I am skeptical of the value of ASLR, it wuold be really
> embarrassing to run into a security issue that's exploitable only
> because Emacs disables ASLR for unexec builds.

We disable ASLR only during the build, AFAIR, not when we run the
dumped Emacs.

> >> DOS in particular is what triggered my question: given the limitations
> >> of DOS systems, it's quite possible temacs-as-emacs just wouldn't fly on
> >> those machines.
> >
> > Those limitations are not relevant in our case.
> 
> I think it's relevant whether DOS will become completely unusable or
> merely difficult to use once unexec is removed, and what can be done to
> fix it.

I was talking specifically about running temacs.

> Does the DOS port work on free DOS clones?

Yes, AFAIK (although I myself only run the DOS port on Windows for
many years now).

> And is there a way to gain access to a Solaris machine to fix
> pdumper on it?

No idea, perhaps Po Lu does.

Re: Solaris dldump

[Corwin Brust]

On Mon, Aug 19, 2024 at 9:39 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Mon, 19 Aug 2024 13:46:11 +0000
> > From: Pip Cet <pipcet@protonmail.com>
> > Cc: luangruo@yahoo.com, stefankangas@gmail.com, ali_gnu2@emvision.com, emacs-devel@gnu.org
> >
>
> > And is there a way to gain access to a Solaris machine to fix
> > pdumper on it?
>
> No idea, perhaps Po Lu does.
>

It may be worth reaching out the GCC devs/testers - a peer on the FSF
sysadmin team thinks they may have a few machines running Solaris (but
isn't sure if 10 or 11 or both).

Re: Solaris dldump

[Corwin Brust]

On Mon, Aug 19, 2024 at 10:26 AM Corwin Brust <corwin@bru.st> wrote:
>
> It may be worth reaching out the GCC devs/testers - a peer on the FSF
> sysadmin team thinks they may have a few machines running Solaris (but
> isn't sure if 10 or 11 or both).

More information!

cfarm210: Solaris 10

See:  https://portal.cfarm.net/machines/list/

Re: Solaris dldump

[Stefan Kangas]

Pip Cet <pipcet@protonmail.com> writes:

> I've just gone through configure.ac removing all the code that depends
> on unexec (no doubt I've missed some), and I must say I now agree it is
> time for unexec to go.  In particular, it had so far escaped my
> attention that it's incompatible with native compilation!
>
> So I'll update the scratch/no-purespace branch to also remove unexec,
> and of course I'm offering to help anyone who wants to fix the remaining
> non-pdumper ports.

Thanks for working on this.  Please push the branch to Savannah when
its ready, and let's take it from there.

Re: Solaris dldump

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Fedora 40's remaining support period is shorter; should we not cease to
> support it any longer,

We seem to be miscommunicating.  I'm not suggesting explicitly
desupporting Solaris 10.

Spending considerable time on keeping the unexec build alive has stopped
making sense for the project as a whole.  The good news is that there is
nothing to suggest that the portable dumper should not be fixable on the
systems where it's reportedly not yet up to scratch.

I'm saying 1) that the reported problems with the portable dumper on
some proprietary systems (MS-DOS, Windows 98, Solaris 10) should be
fixed, 2) that I do not consider this blocking us from dropping the
unexec build at the present time, and 3) I urged volunteers to step
forward to improve and/or fix pdumper on these systems.

I recommend reading the "Information for Maintainers of GNU Software"
manual to get a better view of some of the principles that are guiding
my thinking:

    https://www.gnu.org/prep/maintain/maintain.html#Platforms

Note in particular this part:

    "Supporting other platforms is optional -- we do it when that seems
    like a good idea, but we don’t consider it obligatory.  If the users
    don’t take care of a certain platform, you may have to desupport it
    unless and until users come forward to help.  Conversely, if a user
    offers changes to support an additional platform, you will probably
    want to install them, but you don’t have to.  If you feel the
    changes are complex and ugly, if you think that they will increase
    the burden of future maintenance, you can and should reject them.
    This includes both free or mainly-free platforms such as OpenBSD,
    FreeBSD, and NetBSD, and nonfree platforms such as Windows."

These are the basics, applicable to the GNU project as a whole.  There
are special considerations for Emacs, of course, some of which have been
indicated in this thread.  For example, we are probably "best-in-class"
among GNU projects when it comes to supporting various platforms, even
very old/obsolete ones, and at the cost of valuable time and resources.

So don't let anyone believe that we rush to leave (even fringe) groups
of users behind for no good reason.  That's just not the case.  But we
do have certain things that we prioritize ahead of others.  That
sometimes means asking for volunteer help to do things that are merely
secondary, if that helps us advance our primary goals.

Right now, it's very clear that the unexec build has reached the end of
the road.  Thus, we must ask volunteers to help us improve pdumper on
systems that, with respect to existing users, are not currently primary
considerations.

I hope that helps make things more clear.

> In any event, I promised to devote some of it to this issue after
> Emacs 30 is released.

That is good and welcome.  Thanks in advance for your efforts.