[Bug tdep/29804] [gdb/tdep, vax] Remove gdbarch_deprecated_function_start_offset

["macro at orcam dot me.uk" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29804

--- Comment #12 from Maciej W. Rozycki <macro at orcam dot me.uk> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.