From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id A60743858292 for ; Fri, 16 Feb 2024 11:34:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A60743858292 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A60743858292 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4190:8020::34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708083298; cv=none; b=bZVu/eF1f9PxsdHh5wjlRK15p+A7pLvPHwsSr22GgRFAOrtjcZ8sFP+e8Fbay79YQALKO+x0HMkUDu18yZ0BIfAgDKPbil81SEou7UDawxAnRquojC27GCkbtW9DuKAGqCZRkQUK2QgeMVNNg9//pyatIw+Wqi6efdFXWBmjkCA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708083298; c=relaxed/simple; bh=bIUcNq+GYBUdMPfgoEBvusBLljKkuDLF7e6eurIV4Qg=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=smlWUsh6sJ8bVm6+M8s833yHVFtH2xCOHGcFWlBNZzOHFg7HelWZK81pRC5TLfY/Xo2ZyFpCv09v+4LWdPHbqXhwXPy04bOWz/lyTI+72K7WE9yxFQN9k+SbFRWT0jiD0EIJu5tiBRZsgYr4k32yVKunqbkJlnr3rcwvh1LSqvM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by angie.orcam.me.uk (Postfix, from userid 500) id 351B592009C; Fri, 16 Feb 2024 12:34:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 2E85D92009B; Fri, 16 Feb 2024 11:34:55 +0000 (GMT) Date: Fri, 16 Feb 2024 11:34:55 +0000 (GMT) From: "Maciej W. Rozycki" To: Paul Koning cc: Segher Boessenkool , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Turn on LRA on all targets In-Reply-To: <2A759520-2D62-472E-A97F-35E09B6E50F5@comcast.net> Message-ID: References: <283c45ca085ced958cbce6e64331252c83a5899f.1682268126.git.segher@kernel.crashing.org> <20230423203328.GL19790@gate.crashing.org> <2A759520-2D62-472E-A97F-35E09B6E50F5@comcast.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3488.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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 Thu, 15 Feb 2024, Paul Koning wrote: > > On May 15, 2023, at 5:09 PM, Maciej W. Rozycki wrote: > > > > ... > > > > I may choose to implement a non-DWARF unwinder instead, as the VAX stack > > frame is always fully described by the hardware and there is never ever a > > need for debug information to be able to decode any VAX stack frame (the > > RET machine instruction uses the stack frame information to restore the > > previous PC, FP, SP, AP and any static registers saved by CALLS). > > That would make sense; it's like the heuristic unwinder found in some > other targets (I remember the MIPS one, which worked fairly well and > allowed debugging without useable debug data). Not really, in particular because EH unwinding has to be reliable and heuristics inherently is not. The MIPS heuristic unwinder continues living in GDB; I have extended it to the microMIPS ISA at one point. It has a major flaw though: the MIPS psABI uses a variable frame layout, with the frame maintained solely by software and with no fixed hardware frame pointer, so to analyse it in the absence of debug information the instruction sequence of the function's in question prologue has to be decoded to discover the location of individual frame slots. 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. 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. A mixed approach by interpreting lightweight PDR (Procedure Description Record) information inherited from the ECOFF Mdebug format combined with function prologue scanning might be more reliable, because in that case frame slot positions are known and the only unknown is the code locations they are initialised each at. So all the prologue scanner has to know it is the store machine instructions and any that set a frame pointer from the stack pointer. All the other instructions can be simply ignored. And then only in the innermost frame, because any outer frames must have been fully set up already. But I never got to implementing it and remnants of the PDR unwinder have long been removed from GDB. 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. Therefore to unwind a VAX frame steps similar to those made by hardware on a function return (machine RET instruction) can simply be recreated from information produced by hardware at the function call and recorded in the stack frame and registers. There is room reserved in the stack frame for a pointer to an exception handler even ("condition handler" in VAX-speak), preset to zero (a null pointer) by hardware at function entry. It does seem really attractive (and saves some storage space, which VAX hardware users will likely appreciate), but implies dedicated libgcc code as opposed to reusing common bits, which may or may not be welcome by the community for such an exotic corner case target. Maciej