From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id B1C57385829E for ; Fri, 16 Feb 2024 13:49:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B1C57385829E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B1C57385829E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=63.228.1.57 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708091395; cv=none; b=MxOc9qIukYffc3NW5zWdw+HzsjtTHNC+Wud1dXUtwOKlhF7WgWvMuEZiC7IuQE5CnszmuVGBilv8zmg6McoAlEX7fPS3j3gDzbB6NWAuNA5YD7Oz9RLB645QGRWvsHZpkeoVZrptESOoNe0VeUuEGLSD8B05It/pEbj30h0ofw8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708091395; c=relaxed/simple; bh=UQMvYDTec31qZfI34qtrw/3xQ4Ka39BAf+UBoyRGUCI=; h=Date:From:To:Subject:Message-ID:Mime-Version; b=VX3Gr5ypSo5ajbd7v6yZ9yj2tZOzbL76cBQNDxh3o8hrmWu0DFdVo27YAKbEjWFfDzVh5J3SRIDGt81q4S13HWaIQTZOuVQ9on8i/Ex8df3xVhsi5gcrfY9yuOvsFyW+wRAaEOYNccd7cp5LUhFg2Oz/CWJ28WevmuXHtq1/SDQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 41GDlnuI012698; Fri, 16 Feb 2024 07:47:49 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 41GDlmtg012697; Fri, 16 Feb 2024 07:47:48 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 16 Feb 2024 07:47:48 -0600 From: Segher Boessenkool To: "Maciej W. Rozycki" Cc: Paul Koning , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Turn on LRA on all targets Message-ID: <20240216134748.GF19790@gate.crashing.org> References: <283c45ca085ced958cbce6e64331252c83a5899f.1682268126.git.segher@kernel.crashing.org> <20230423203328.GL19790@gate.crashing.org> <2A759520-2D62-472E-A97F-35E09B6E50F5@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Feb 16, 2024 at 11:34:55AM +0000, Maciej W. Rozycki wrote: > Not really, in particular because EH unwinding has to be reliable and > heuristics inherently is not. Yup. Which is why I did 0359465c703a for rs6000 six years ago (how time flies!) The commit message for that includes To find out where on-entry register values live at any point in a program, GDB currently tries to parse to parse the executable code. This does not work very well, for example it gets confused if some accesses to the stack use the frame pointer (r31) and some use the stack pointer (r1). A symptom is that backtraces can be cut short. and the patch does + /* By default, always emit DWARF-2 unwind info. This allows debugging + without maintaining a stack frame back-chain. It also allows the + debugger to find out where on-entry register values are stored at any + point in a function, without having to analyze the executable code (which + isn't even possible to do in the general case). */ +#ifdef OBJECT_FORMAT_ELF + opts->x_flag_asynchronous_unwind_tables = 1; +#endif We went through very many refinements of the heuristics through the years, but at some point you just have to give up: heuristics never can make up for missing information. > Consequently the more aggressive the compiler has become to schedule > function body instructions within a function's prologue the more lost the > machine code interpreter has become. Ultimately it would have to become a > full-fledged CPU simulator to do its heuristics. Yup, exactly. > In reality it means the > unwinder may fail to produce acceptable results, which will happen at any > frequency between hardly ever to most often, depending on the exact > circumstances. Yes. If the compiler optimises the *logue code well, there is no way heuristics can follow that. > Conversely no heuristics is required to unwind VAX frames, because they > are fixed in layout by hardware, fully self-described, and with the > hardware frame pointer always available. The downside of the VAX situation of course is that the compiler has no freedom to optimise the frame and *logue code at all, let alone well. This may not matter so much on narrow ucoded in-order machines, there are different balances there :-) Segher