From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5C8873858CDA; Sat, 28 Jan 2023 14:09:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5C8873858CDA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674914949; bh=xtEfH2HyyxNE+zTP/EcCFR6gBr6i2lFQXedbPuY5Ybw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bdeXnvqzS4wV0e7wB6YzhxeVudAw+fd1Aq3edgKV6vskJJr+xCBwhUzcXwVygUNWD 4rSjizvjZTyIeCFR8dOHt7PUf+efqsHL1MYu8KXdMfQEr/qabAU/VrTRPOyb4fxoOy w0Q87p4z1Dh7vr+9tOrWuZbBEGOWYkTn59y4xDbU= From: "macro at orcam dot me.uk" To: gdb-prs@sourceware.org Subject: [Bug tdep/29804] [gdb/tdep, vax] Remove gdbarch_deprecated_function_start_offset Date: Sat, 28 Jan 2023 14:09:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: tdep X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: macro at orcam dot me.uk X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29804 --- Comment #12 from Maciej W. Rozycki --- For the record, I have VAX/NetBSD `gdbserver' implemented however due to non-functional exception handling with this configuration it always crashes upon exit with: terminate called after throwing an instance of 'gdb_exception_quit' terminate called recursively Abort Similarly does native GDB as included with the distribution, e.g.: (gdb) ^Cterminate called after throwing an instance of 'gdb_exception_RETURN_MASK_QUIT' terminate called recursively Abort I have assessed the problem and concluded that the generic DWARF unwinder included with libgcc is unsuitable as it stands for the VAX frame layout, because it makes too many assumptions that are wrong for the VAX ABI. Most importantly it thinks that it needs to update $sp to unwind a frame, but it has to be $fp with the VAX ABI ($sp only really matters for outgoing function arguments and alloca, $ap is used for incoming function arguments, and $fp is used for everything else). And in any case DWARF EH records produced by GCC for the VAX target are broken in many ways. AFAICT exception handling has never worked for the ELF VAX/NetBSD target (perhaps it worked for a.out). With the VAX ABI however there is full frame information always available (the RET machine instruction makes use of it to restore all the static registers saved by the CALLS instruction and move to the previous frame) and one does not need to resort to DWARF records to be able to refer to arbitrary frames (perhaps except for signal frames; I have not checked that yet). Therefore I have not decided yet whether the solution for exception handling will be a VAX-specific implementation of a DWARF unwinder or a completely different VAX-specific unwinder working directly on the frame structure itself. I do hope to get it sorted with GCC 14 later this year. Anyway this implementation of `gdbserver' is otherwise fully functional and has turned out good enough to figure out what is going on with frame unwinding, so I'll see if it is suitable to run regression testing despite of crashing upon exit and will submit it anyway. There is a change or two required to GDB itself to make the testsuite work with the generic core of NetBSD `gdbserver', which makes me suspect remote regression testing has never ever been run with any NetBSD target. --=20 You are receiving this mail because: You are on the CC list for the bug.=