From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 6D3B4384F6FA; Fri, 18 Nov 2022 10:20:15 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6D3B4384F6FA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1668766815;
	bh=hOEHWm9JB8iXOkY8K+VdZPpykMPC/itfIgR75N+uJHE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=jWXaWNHljOGa+gEQmfNim2jubCFxBrG+t8L3oYWiYTgAUf9TknIpFk4FmncgDtF/s
	 gnHfj0esMK1+nZe0KM0PzRRWWpyUxoE4NXPfCAwuZ41KowDNhZF5njDOxx+iyjal3K
	 GHas5TPwWv+BP/RWf/FNJwIzwhx62l24EsQay+FY=
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug tdep/29804] [gdb/tdep, vax] Remove
 gdbarch_deprecated_function_start_offset
Date: Fri, 18 Nov 2022 10:20:14 +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: vries at gcc dot gnu.org
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: <bug-29804-4717-gumAurFXdH@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-29804-4717@http.sourceware.org/bugzilla/>
References: <bug-29804-4717@http.sourceware.org/bugzilla/>
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: <gdb-prs.sourceware.org>

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> Thing is, this conversion is exactly what CONVERT_FUNC_PTR_ADDR is for.=20

It's debatable whether we should use convert_from_func_ptr_addr or
gdbarch_skip_entrypoint.

In practise the determining factor for which to use could be just where the=
 two
are used in the code.

Indeed the description of convert_from_func_ptr_addr (as confusingly given =
in
the comment for gdbarch_deprecated_function_start_offset) seems to fit nice=
ly:
...
/* A function can be addressed by either it's "pointer" (possibly a=20=20=
=20=20=20=20=20=20=20=20=20=20=20
   descriptor address) or "entry point" (first executable instruction).=20=
=20=20=20=20=20=20=20=20
   The method "convert_from_func_ptr_addr" converting the former to the=20=
=20=20=20=20=20=20=20=20
   latter.  gdbarch_deprecated_function_start_offset is being used to imple=
ment=20
   a simplified subset of that functionality - the function's address=20=20=
=20=20=20=20=20=20=20=20=20
   corresponds to the "function pointer" and the function's start=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20
   corresponds to the "function entry point" - and hence is redundant. */
...

But I also saw in the gcc backend:
...
/* Output code to add DELTA to the first argument, and then jump to FUNCTIO=
N.=20=20=20
   Used for C++ multiple inheritance.=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20
        .mask   ^m<r2,r3,r4,r5,r6,r7,r8,r9,r10,r11>  #conservative entry ma=
sk=20=20=20
        addl2   $DELTA, 4(ap)   #adjust first argument=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
        jmp     FUNCTION+2      #jump beyond FUNCTION's entry mask=20=20=20=
=20=20=20=20=20=20=20=20=20=20
              ...
So, we could describe this situation by saying there are two entry points f=
or
FUNCTION:
- one for calls (target address at mask), and
- one for jumps (target address past mask).

Indeed

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