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

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

--- 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. 

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 nicely:
...
/* A function can be addressed by either it's "pointer" (possibly a             
   descriptor address) or "entry point" (first executable instruction).         
   The method "convert_from_func_ptr_addr" converting the former to the         
   latter.  gdbarch_deprecated_function_start_offset is being used to implement 
   a simplified subset of that functionality - the function's address           
   corresponds to the "function pointer" and the function's start               
   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 FUNCTION.   
   Used for C++ multiple inheritance.                                           
        .mask   ^m<r2,r3,r4,r5,r6,r7,r8,r9,r10,r11>  #conservative entry mask   
        addl2   $DELTA, 4(ap)   #adjust first argument                          
        jmp     FUNCTION+2      #jump beyond FUNCTION's entry mask             
              ...
So, we could describe this situation by saying there are two entry points for
FUNCTION:
- one for calls (target address at mask), and
- one for jumps (target address past mask).

Indeed

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