From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: STatus of MPS branch Date: Mon, 22 Apr 2024 07:28:40 +0200 Message-ID: References: <878r16n5jl.fsf@gmail.com> <87ttjulb16.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38835"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 22 07:29:31 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 1rymF7-0009qm-QH for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Apr 2024 07:29:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rymER-0001c6-76; Mon, 22 Apr 2024 01:28:47 -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 1rymEP-0001bp-N7 for emacs-devel@gnu.org; Mon, 22 Apr 2024 01:28:45 -0400 Original-Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rymEN-0001YH-V4 for emacs-devel@gnu.org; Mon, 22 Apr 2024 01:28:45 -0400 Original-Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-56e56ee8d5cso4952832a12.2 for ; Sun, 21 Apr 2024 22:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713763722; x=1714368522; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=mbvUgf05vOCJK2SKLoCooHSlS9FjQyCkHUPGcaK2hZY=; b=FCus1b0q9KmIruwhOImKXu9mLyqW2oWYmf7PQFnaaMMCtmu/64MIdIC5SXxw5WEgeL bu/Brkj52lrAwSZ36piehET6T+H2zJHyZbIYh4+JNouVjjBnxn3HJMaEZKzwobQqET7I aRSpLY8kGvi12enhAb18UaQS5bk2OvZnclGVTQsVIu7CT8hm9fHoANbh+qr/mRc2OkQn oYXjg4252zdb1TZK9X0t5aG/ebY4Oqb/T76FAHAJ2an7LtdouWae1jcnyfPfDFtOiPdI MKrHw5jAkJ5+KZ0BunX2saA5WCVyKYabj+9dgklpgJegGAJjUIehug1+ImYPiF4Zb+91 PhKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713763722; x=1714368522; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mbvUgf05vOCJK2SKLoCooHSlS9FjQyCkHUPGcaK2hZY=; b=w6gMGoHQbR8rOKUDt8aVGm84lV2IBswHahtwvpfPOWuksYse5RpIO9cxzI4Ivee46m IpzpF3tBBjbT3RpIfJn1RUzsNhGY3SUkhGs7c70nhNWN3H/NbySNTVVZoKVYrtajZYvT o9R+uFoONGryHSCkAs34p9YLereTtmcIbTzPqx+Mssm+wd2kEHVRRVZ8ScFNltNQEqaB Y1CddBIR1WPFtJjyUlbGDfhED+s2Bqf1sI4l5BQydI8xjTIayW6CyTPPzoTPjzSWrOdB iVWKcBjYPWXc+vgL7rAVSt2OXe/36UNAb0J822Hif56uDFlFN+GQ0RpSdcoMMJElJHzV kWmw== X-Gm-Message-State: AOJu0YyCutYjqR6J4ndBHoXZJ1jyke158PJ7KQreRGBFgSgDwFNfzjgE 3wlxLHrAzeYrbh28O8Yxs/fUQl0JE7UOfyD7e3Z9CB8rkreIs7zyT/Yc8Q== X-Google-Smtp-Source: AGHT+IHmjGSfvMAy4JYXP6hIEezaEei+EL7lxEMBpyzClUqFqfVKH96iIQStx/Xl4WXsuOzoB0ORjg== X-Received: by 2002:a50:9508:0:b0:56e:2e9b:1341 with SMTP id u8-20020a509508000000b0056e2e9b1341mr5807008eda.38.1713763722064; Sun, 21 Apr 2024 22:28:42 -0700 (PDT) Original-Received: from Pro.fritz.box (p4fe3af79.dip0.t-ipconnect.de. [79.227.175.121]) by smtp.gmail.com with ESMTPSA id d6-20020a50fb06000000b005705e7ee65esm5109227edq.56.2024.04.21.22.28.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Apr 2024 22:28:41 -0700 (PDT) In-Reply-To: <87ttjulb16.fsf@gmail.com> (Helmut Eller's message of "Sun, 21 Apr 2024 22:24:05 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::531; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x531.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:317947 Archived-At: Helmut Eller writes: > I changed some things and now I can no longer reproduce the exact same > problem. But it looked to me like a perfectly normal string with > intervals=3D0x0. Strangely, accessing the intervals field from GDB didn't > cause any SIGSEGV. > > However, after setting breakpoints in handle_sigsegv and sigHandle (from > MPS) I discovered that sigHandle wasn't called. So my hypothesis is > that the signal handler isn't initialized properly. In particular, it > seems problematic that ProtSetup (from MPS) is called before > init_signals. > > Then I moved the call to init_signals in emacs.c up before the call to > init_igc and voil=C3=A0: the build completed. With an apparently working > (tty-only) Emacs. Oh, I have an idea! Hopefully I can explain it. Let me try... MPS is a copying GC, and it uses read-barriers for object forwarding. Let's say O is an object managed by MPS, and it decides during GC that O shall be moved in memory to the new location N. This is done by copying O to N, storing at O the information that it has moved to N, and putting a read-barrier on O. The last step means that any access to O by the client (Emacs) leads to MPS being involved, which updates the reference to O to a reference to N. Plus... MacOS has a kernel that is, let's not get into details, a conglomerate of Mach and FreeBSD kernel. This means MPS can use Mach mechanisms for implementing read/write barriers, and I know it does because I landed in that code in LLDB at some point. Linux is not Mach, so MPS must use VM protection and signals. And finally, the idea now would be that MPS's signal handling (probably SIGSEGV and SIGBUS) and Emacs' signal handling interfere with one another. For example, MPS has done its thing and read-protected O from above. Emacs accesses O, a SEGV is signaled, Emacs gets the signal and thinks it's bit the dust. And so on. Or, IOW, we need some Emacs signal handling support personal. Does that make sense?