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: MPS: native comp Date: Thu, 09 May 2024 11:12:34 +0200 Message-ID: References: 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="35959"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org, Helmut Eller To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 09 11:13:37 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 1s4zqK-00096i-Oq for ged-emacs-devel@m.gmane-mx.org; Thu, 09 May 2024 11:13:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s4zpT-0006W0-7K; Thu, 09 May 2024 05:12:43 -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 1s4zpQ-0006SQ-8L for emacs-devel@gnu.org; Thu, 09 May 2024 05:12:41 -0400 Original-Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s4zpO-0005CU-H7; Thu, 09 May 2024 05:12:39 -0400 Original-Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a59a387fbc9so154205166b.1; Thu, 09 May 2024 02:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715245956; x=1715850756; 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=VvzN6XiZVqm+zQys6KCpfWs8rW1x/gRNIKmTvrGUoY0=; b=fRqkvML7SxVGUOsytEA2R3LLnVFgS2tgIu1zk6S0C0ZtA9jMke4mUI6lh+6YyivYfR DoODgYa7wCUMcOSYHAzCb//Q9Pfztn2VJMgHeLIbJTmEPdnqe1EI7TtmTIX56G9TDRv8 RMdJoFTN1XPSsy7YP1JAojTZV+Lg8LWg8eCsFa6Wk2YmHk7scNgS327ONVa+R3KVA+3k Xw0FFSdJmC8BTceopVDcxNMzfYMsVpNlujKy9SzuE7ILhOgZbsQP9n8ykx8SiSQIeNuw GIljPFj5ZKvId9f9d2ZGoiS8+EULZ5jBzJo6g6hRffzabnZcEdvF/NZGqFSQxtZks9FG zWEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715245956; x=1715850756; 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=VvzN6XiZVqm+zQys6KCpfWs8rW1x/gRNIKmTvrGUoY0=; b=kYpKI+YCq1hlHEiULSVjXCqn5k3cQDRR6ugZBDAyDTC5ZHjd5cuPnqOkbuQDuFPREP LhXDAQ/MerAIXgsbK3GkYWj/4bk2HjanJwKNmdoru0ru0Xy1H5f0i7gBK+92GCqRPZPZ qPDNI8GWU1YRA/jcgjWQhaNZAT3NPZjyu3ds7aV4Fl8QjSu/GjyZzJzshcln7RBVEuSb S2+XrhGDSeZgoc1eyHzox50FwUi53po8AJv/mm6mJ+9jgSWL8UEhYbKcWgxfPD+cvm32 7ocWcj+29Iw0IOxY3jcCZKcw8tXe4K8F5cptjcu3WjkRgn3CkUNUpT9O2AvLB08OjMBJ 2SwQ== X-Forwarded-Encrypted: i=1; AJvYcCWow/YsOQxbzYxt8BQbGkBOzqFGpHNvaHYrCyQJIuwF3cNuiJr2A04Uh7DXRQPe+Xm7lP+DLlPFD3nuul9ZWNbi4Gri X-Gm-Message-State: AOJu0Yw/hx7G2cR97TF4n7ueSaSY0dt1y1HBH94LpukdOAnPqV5yY0r6 0wcV0VqK0r8ADa9epRkUvHBcj2n8xiZq4xH0ldINzVUNc+Do7euGA4G15w== X-Google-Smtp-Source: AGHT+IEal3EiEspm1r++FaQBCrtl2Qv7mTzXmLGJtvCHxmOZYUCPfs5w/TKKK8b+D/uK4FFNz7vcyg== X-Received: by 2002:a17:906:858:b0:a59:c3bb:b83b with SMTP id a640c23a62f3a-a59fb923262mr258184266b.1.1715245955896; Thu, 09 May 2024 02:12:35 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36021.dip0.t-ipconnect.de. [217.227.96.33]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a5a179c81b4sm52208766b.113.2024.05.09.02.12.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 May 2024 02:12:35 -0700 (PDT) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Thu, 09 May 2024 08:15:20 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::62a; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62a.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:319056 Archived-At: Gerd M=C3=B6llmann writes: > Gerd M=C3=B6llmann writes: > >> Andrea Corallo writes: >> >>>> Current_thread is staticpro'd, so in Emacs we'll fix that if a >>>> thread_sate moves in memory. But what does/could GCC assume about this, >>>> or maybe comp? >>> >>> I think we'll have to update "struct comp_thread_state * * >>> current_thread_reloc" as well if 'current_thread' moves. >> >> Thanks. >> >> BTW, is there a way to let libgccjit keep to .o file together with the >> .c file? >> >> I'm asking because the .elns don't have debug info on macOS (for a >> long-winded reason that made macOS handle DWARF differently from the >> rest). If I had a .o with debug info, I could maybe generate .dSYM >> files. > > Good news! I think I know what's going on, 100% - epsilon. > > The error occurs in an Emacs that has a pdump loaded. (I submitted a bug > concerning the build process. The workaround for this made it much > easier for me to recognize what's going on.) > > The loaded dump contains, among other things, native compilation unit > objects. These objects contain pointers into the loaded .eln for things > that we need to trace. For CUs that are in MPS memory, this is done by > fix_comp_unit and all it good. For CUs in the dump this is not done, > simply because they are not in MPS memory but in the hot segment of the > loaded dump. Result is that references in these .eln are not fixed, and > so on. > > In the end, it's always the same problem with the dump. The dump is not > in MPS, MPS knows only traces as an ambig root. > > I guess we should do something about this. Maybe we could try Helmut's > idea of copying the objects to MPS. > > Meanwhile, I'll try to come up with a workaround. Bad news! I added a workaround but it's not the fix. At least not completely. The build with native compilation still fails, at a different point, but with the same symptom that we hit an unfixed reference. This time Ffuncall is called from a native-compiled bytecomp--check-eq-args with a symbol pointing to a tombstone. So the original question how to get debug info for .elns (maybe by keeping .o files, as I mentioned) is still important. I'll transfer what I have later to scratch/igc.