unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: eller.helmut@gmail.com, acorallo@gnu.org, emacs-devel@gnu.org
Subject: Re: MPS codegen
Date: Sat, 15 Jun 2024 10:34:43 +0300	[thread overview]
Message-ID: <86cyoiwtf0.fsf@gnu.org> (raw)
In-Reply-To: <m2msnmn0jx.fsf@pro2.fritz.box> (message from Gerd Möllmann on Sat, 15 Jun 2024 09:10:42 +0200)

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  acorallo@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 09:10:42 +0200
> 
> >> Pdumper can use, among other methods, mmap'd files. In that case
> >> munmap'ing could write changes back to disk. So pdumper rather marks the
> >> region as not needed. At least that's how I understand it.
> >
> > But it doesn't protect the region from being accessed, AFAIU.  By
> > contrast, on MS-Windows we do this:
> >
> >       (void) VirtualProtect (mem, size, PAGE_NOACCESS, &old_prot);
> >
> > which will then cause an access violation if any address within the
> > region is accessed in any way (read or write).  If you do the same
> > with mmap and PROT_NONE, does the build still work and does the built
> > Emacs succeed to start?
> 
> I'd rather if you comment out the discard_dump in igc.c, in mirror_dump
> and see if that's the problem.

And if disabling that eliminates the segfault, what will we do then?

IMO, getting Emacs to segfault on all systems due to access to the
discarded pdumper memory is the way forward: it allows all of us
(rather than just me) investigate the invalid access and fix it.

> The fwd causing the problem should point to Emacs' data segment, not
> the dump. The variable is a DEFVAR_BOOL.

Sorry, I don't understand what you mean here.  If I can help by
providing some information from my build here, please elaborate.

> > Note that originally pdumper.c called dump_discard_mem only for
> > sections considered discardable:
> >
> >   sections[DS_DISCARDABLE].spec = (struct dump_memory_map_spec)
> >     {
> >      .fd = dump_fd,
> >      .size = header->cold_start - adj_discardable_start,
> >      .offset = adj_discardable_start,
> >      .protection = DUMP_MEMORY_ACCESS_READWRITE,
> >     };
> >   [...]
> >   dump_mmap_discard_contents (&sections[DS_DISCARDABLE]);
> >
> > Whereas the code in igc.c seems to discard all of the memory loaded
> > from the pdumper file, or am I missing something?
> 
> It's the hot section that igc discards. The pdumper can only discard the
> relocs which are not longer needed once they have been processed. The
> theory is that it's no longer needed since we have made a copy.

Evidently, something was not done properly while copying, I guess?



  reply	other threads:[~2024-06-15  7:34 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-10 13:39 MPS: Update Gerd Möllmann
2024-06-10 16:17 ` Andrea Corallo
2024-06-10 16:26   ` Gerd Möllmann
2024-06-10 16:44     ` Gerd Möllmann
2024-06-10 20:58       ` Andrea Corallo
2024-06-11  3:12         ` Gerd Möllmann
2024-06-11 20:35 ` Helmut Eller
2024-06-12  4:45   ` Gerd Möllmann
2024-06-12  7:54     ` Eli Zaretskii
2024-06-12  8:00       ` Gerd Möllmann
2024-06-13  9:07         ` MPS codegen (was: MPS: Update) Helmut Eller
2024-06-13 12:33           ` MPS codegen Gerd Möllmann
2024-06-13 17:48             ` Helmut Eller
2024-06-13 18:24               ` Gerd Möllmann
2024-06-13 18:31                 ` Gerd Möllmann
2024-06-13 18:38                 ` Helmut Eller
2024-06-13 18:54                   ` Gerd Möllmann
2024-06-13 19:15                     ` Helmut Eller
2024-06-13 19:37                       ` Gerd Möllmann
2024-06-14  6:37                         ` Eli Zaretskii
2024-06-14  7:30                           ` Gerd Möllmann
2024-06-14  7:56                             ` Gerd Möllmann
2024-06-14 10:52                               ` Eli Zaretskii
2024-06-14 10:46                             ` Eli Zaretskii
2024-06-13 23:09                 ` Andrea Corallo
2024-06-14  6:08                   ` Gerd Möllmann
2024-06-14  7:45                     ` Helmut Eller
2024-06-14  7:59                       ` Gerd Möllmann
2024-06-14  8:28                         ` Gerd Möllmann
2024-06-14  8:51                           ` Helmut Eller
2024-06-14 11:32                             ` Eli Zaretskii
2024-06-14 12:43                               ` Gerd Möllmann
2024-06-14 13:04                                 ` Eli Zaretskii
2024-06-14 13:17                                   ` Gerd Möllmann
2024-06-14 13:46                                     ` Eli Zaretskii
2024-06-14 14:05                                       ` Gerd Möllmann
2024-06-14 14:33                                         ` Eli Zaretskii
2024-06-14 14:46                                           ` Gerd Möllmann
2024-06-14 16:30                               ` Helmut Eller
2024-06-14 18:28                                 ` Eli Zaretskii
2024-06-14 19:03                                   ` Eli Zaretskii
2024-06-14 19:26                                     ` Helmut Eller
2024-06-14 19:50                                       ` Gerd Möllmann
2024-06-15  6:26                                         ` Eli Zaretskii
2024-06-15  7:10                                           ` Gerd Möllmann
2024-06-15  7:34                                             ` Eli Zaretskii [this message]
2024-06-15  8:22                                               ` Gerd Möllmann
2024-06-15  6:11                                       ` Eli Zaretskii
2024-06-15  7:25                                         ` Gerd Möllmann
2024-06-15  7:46                                           ` Eli Zaretskii
2024-06-15  8:14                                             ` Gerd Möllmann
2024-06-15  8:38                                               ` Gerd Möllmann
2024-06-15  8:44                                                 ` Helmut Eller
2024-06-15  8:56                                                   ` Gerd Möllmann
2024-06-15  9:07                                                     ` Helmut Eller
2024-06-15  9:27                                                       ` Gerd Möllmann
2024-06-15 12:33                                                     ` Gerd Möllmann
2024-06-16  6:16                                                       ` Gerd Möllmann
2024-06-16  7:53                                                         ` Eli Zaretskii
2024-06-16  8:19                                                           ` Gerd Möllmann
2024-06-16  8:40                                                             ` Helmut Eller
2024-06-16  8:49                                                               ` Gerd Möllmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86cyoiwtf0.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=acorallo@gnu.org \
    --cc=eller.helmut@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=gerd.moellmann@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).