From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS codegen Date: Sat, 15 Jun 2024 10:34:43 +0300 Message-ID: <86cyoiwtf0.fsf@gnu.org> References: <86r0d21tqj.fsf@gnu.org> <877cetgqiz.fsf_-_@gmail.com> <87wmmsg2e4.fsf@gmail.com> <878qz8ezn4.fsf@gmail.com> <8734pfgb51.fsf@gmail.com> <86ikybyd2h.fsf@gnu.org> <87v82bebc6.fsf@gmail.com> <86wmmrwf86.fsf@gnu.org> <86r0czwdmc.fsf@gnu.org> <87jzire36a.fsf@gmail.com> <86o782wwl4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23325"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, acorallo@gnu.org, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 15 09:35:42 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sINwr-0005pO-Ju for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Jun 2024 09:35:41 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sINw3-0007jR-0s; Sat, 15 Jun 2024 03:34:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sINw0-0007iw-CO for emacs-devel@gnu.org; Sat, 15 Jun 2024 03:34:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sINvy-0003SB-Gs; Sat, 15 Jun 2024 03:34:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=mQdQiQw1jpo8fmKbaPC7kWtOM9JoNDruTSW9hWOPSAg=; b=OhSHk4P7iDBJ3l04Vl3/ 32i6qXpgeBgSVKk+gMbctnbGvu8Q6MtFLm/ZFEmztMxLJDsdOnVr6WFuNIwswbcvrqwlVftDu+ONp j8gMvEBGCzNhuLdMhQFgNZFfRcnfnLSHxSk+U89aeehkZr04sPza0nd3aNt/JuAGGfNhGCJoBo1j5 sH2C9UXPbFfKqhGmXBG1UR69pLqgzKdxyfUuTiRF0gmZLIo5gugsP0ITagIm3yJ2LJ+CLqA0qFM7Y CxzHl+GgrLXKzhoJQLSLc7pS2Smtz23KDCQlSBJgAdW/NiZ9fFHSJiR/K/Q949IuaAA0ZtWASa/6+ rcUOJE/9rVIdVg==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sat, 15 Jun 2024 09:10:42 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:320107 Archived-At: > From: Gerd Möllmann > 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 (§ions[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?