[ppc64-linux] gdbarch hook to find true execution entry point

[ppc64-linux] gdbarch hook to find true execution entry point

[Jim Blandy]

2003-06-11  Jim Blandy  <jimb@redhat.com>

	* gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method.
	* arch-utils.c (generic_bfd_entry_point): New function.
	* arch-utils.h (generic_bfd_entry_point): New declaration.
	* gdbarch.c, gdbarch.h: Regenerated.
	* solib-svr4.c (enable_break): Call it, instead of accessing
	tmp_bfd->start_address directly.
  
Index: gdb/gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.237
diff -c -r1.237 gdbarch.sh
*** gdb/gdbarch.sh	17 May 2003 05:59:58 -0000	1.237
--- gdb/gdbarch.sh	11 Jun 2003 13:16:31 -0000
***************
*** 654,659 ****
--- 654,664 ----
  f:2:TARGET_PRINT_INSN:int:print_insn:bfd_vma vma, disassemble_info *info:vma, info:::legacy_print_insn::0
  f:2:SKIP_TRAMPOLINE_CODE:CORE_ADDR:skip_trampoline_code:CORE_ADDR pc:pc:::generic_skip_trampoline_code::0
  
+ # The actual code address at which ABFD would begin execution.  Note
+ # that on some architectures (like 64-bit PowerPC Linux),
+ # bfd_get_start_address actually points to a function descriptor, not
+ # the start function's entry point itself.
+ m:1::CORE_ADDR:bfd_entry_point:bfd *abfd:abfd:::generic_bfd_entry_point::0
  
  # For SVR4 shared libraries, each call goes through a small piece of
  # trampoline code in the ".plt" section.  IN_SOLIB_CALL_TRAMPOLINE evaluates
Index: gdb/arch-utils.c
===================================================================
RCS file: /cvs/src/src/gdb/arch-utils.c,v
retrieving revision 1.83.4.1
diff -c -r1.83.4.1 arch-utils.c
*** gdb/arch-utils.c	11 Jun 2003 06:40:14 -0000	1.83.4.1
--- gdb/arch-utils.c	11 Jun 2003 13:16:26 -0000
***************
*** 375,380 ****
--- 375,386 ----
    return 0;
  }
  
+ CORE_ADDR
+ generic_bfd_entry_point (struct gdbarch *gdbarch, bfd *abfd)
+ {
+   return bfd_get_start_address (abfd);
+ }
+ 
  /* Legacy version of target_virtual_frame_pointer().  Assumes that
     there is an DEPRECATED_FP_REGNUM and that it is the same, cooked or
     raw.  */
Index: gdb/arch-utils.h
===================================================================
RCS file: /cvs/src/src/gdb/arch-utils.h,v
retrieving revision 1.46.4.1
diff -c -r1.46.4.1 arch-utils.h
*** gdb/arch-utils.h	11 Jun 2003 06:40:14 -0000	1.46.4.1
--- gdb/arch-utils.h	11 Jun 2003 13:16:26 -0000
***************
*** 89,94 ****
--- 89,98 ----
     being passed */
  extern int frame_num_args_unknown (struct frame_info *fi);
  
+ /* Return the start address of ABFD.  This is exactly like
+    bfd_get_start_address, except that it's a gdbarch function.  */
+ extern CORE_ADDR generic_bfd_entry_point (struct gdbarch *gdbarch, bfd *abfd);
+ 
  
  /* The following DEPRECATED interfaces are for pre- multi-arch legacy
     targets. */
Index: gdb/gdbarch.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.c,v
retrieving revision 1.216
diff -c -r1.216 gdbarch.c
*** gdb/gdbarch.c	17 May 2003 05:59:58 -0000	1.216
--- gdb/gdbarch.c	11 Jun 2003 13:16:28 -0000
***************
*** 263,268 ****
--- 263,269 ----
    gdbarch_software_single_step_ftype *software_single_step;
    gdbarch_print_insn_ftype *print_insn;
    gdbarch_skip_trampoline_code_ftype *skip_trampoline_code;
+   gdbarch_bfd_entry_point_ftype *bfd_entry_point;
    gdbarch_in_solib_call_trampoline_ftype *in_solib_call_trampoline;
    gdbarch_in_solib_return_trampoline_ftype *in_solib_return_trampoline;
    gdbarch_pc_in_sigtramp_ftype *pc_in_sigtramp;
***************
*** 429,434 ****
--- 430,436 ----
    0,
    0,
    0,
+   generic_bfd_entry_point,
    0,
    0,
    0,
***************
*** 555,560 ****
--- 557,563 ----
    current_gdbarch->smash_text_address = core_addr_identity;
    current_gdbarch->print_insn = legacy_print_insn;
    current_gdbarch->skip_trampoline_code = generic_skip_trampoline_code;
+   current_gdbarch->bfd_entry_point = generic_bfd_entry_point;
    current_gdbarch->in_solib_call_trampoline = generic_in_solib_call_trampoline;
    current_gdbarch->in_solib_return_trampoline = generic_in_solib_return_trampoline;
    current_gdbarch->pc_in_sigtramp = legacy_pc_in_sigtramp;
***************
*** 745,750 ****
--- 748,754 ----
    /* Skip verify of software_single_step, has predicate */
    /* Skip verify of print_insn, invalid_p == 0 */
    /* Skip verify of skip_trampoline_code, invalid_p == 0 */
+   /* Skip verify of bfd_entry_point, invalid_p == 0 */
    /* Skip verify of in_solib_call_trampoline, invalid_p == 0 */
    /* Skip verify of in_solib_return_trampoline, invalid_p == 0 */
    /* Skip verify of pc_in_sigtramp, invalid_p == 0 */
***************
*** 788,793 ****
--- 792,801 ----
                        GDB_MULTI_ARCH);
    if (GDB_MULTI_ARCH)
      fprintf_unfiltered (file,
+                         "gdbarch_dump: bfd_entry_point = 0x%08lx\n",
+                         (long) current_gdbarch->bfd_entry_point);
+   if (GDB_MULTI_ARCH)
+     fprintf_unfiltered (file,
                          "gdbarch_dump: gdbarch_frame_align_p() = %d\n",
                          gdbarch_frame_align_p (current_gdbarch));
    if (GDB_MULTI_ARCH)
***************
*** 5330,5335 ****
--- 5338,5362 ----
                                    gdbarch_skip_trampoline_code_ftype skip_trampoline_code)
  {
    gdbarch->skip_trampoline_code = skip_trampoline_code;
+ }
+ 
+ CORE_ADDR
+ gdbarch_bfd_entry_point (struct gdbarch *gdbarch, bfd *abfd)
+ {
+   gdb_assert (gdbarch != NULL);
+   if (gdbarch->bfd_entry_point == 0)
+     internal_error (__FILE__, __LINE__,
+                     "gdbarch: gdbarch_bfd_entry_point invalid");
+   if (gdbarch_debug >= 2)
+     fprintf_unfiltered (gdb_stdlog, "gdbarch_bfd_entry_point called\n");
+   return gdbarch->bfd_entry_point (gdbarch, abfd);
+ }
+ 
+ void
+ set_gdbarch_bfd_entry_point (struct gdbarch *gdbarch,
+                              gdbarch_bfd_entry_point_ftype bfd_entry_point)
+ {
+   gdbarch->bfd_entry_point = bfd_entry_point;
  }
  
  int
Index: gdb/gdbarch.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.h,v
retrieving revision 1.185
diff -c -r1.185 gdbarch.h
*** gdb/gdbarch.h	17 May 2003 05:59:58 -0000	1.185
--- gdb/gdbarch.h	11 Jun 2003 13:16:29 -0000
***************
*** 2831,2836 ****
--- 2831,2845 ----
  #endif
  #endif
  
+ /* The actual code address at which ABFD would begin execution.  Note
+    that on some architectures (like 64-bit PowerPC Linux),
+    bfd_get_start_address actually points to a function descriptor, not
+    the start function's entry point itself. */
+ 
+ typedef CORE_ADDR (gdbarch_bfd_entry_point_ftype) (struct gdbarch *gdbarch, bfd *abfd);
+ extern CORE_ADDR gdbarch_bfd_entry_point (struct gdbarch *gdbarch, bfd *abfd);
+ extern void set_gdbarch_bfd_entry_point (struct gdbarch *gdbarch, gdbarch_bfd_entry_point_ftype *bfd_entry_point);
+ 
  /* For SVR4 shared libraries, each call goes through a small piece of
     trampoline code in the ".plt" section.  IN_SOLIB_CALL_TRAMPOLINE evaluates
     to nonzero if we are currently stopped in one of these. */
Index: gdb/solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.32.8.2
diff -c -r1.32.8.2 solib-svr4.c
*** gdb/solib-svr4.c	11 Jun 2003 13:00:34 -0000	1.32.8.2
--- gdb/solib-svr4.c	11 Jun 2003 13:16:32 -0000
***************
*** 1022,1028 ****
  	 the current pc (which should point at the entry point for the
  	 dynamic linker) and subtracting the offset of the entry point.  */
        if (!load_addr_found)
! 	load_addr = read_pc () - tmp_bfd->start_address;
  
        /* Record the relocated start and end address of the dynamic linker
           text and plt section for svr4_in_dynsym_resolve_code.  */
--- 1022,1029 ----
  	 the current pc (which should point at the entry point for the
  	 dynamic linker) and subtracting the offset of the entry point.  */
        if (!load_addr_found)
! 	load_addr = (read_pc ()
!                      - generic_bfd_entry_point (current_gdbarch, tmp_bfd));
  
        /* Record the relocated start and end address of the dynamic linker
           text and plt section for svr4_in_dynsym_resolve_code.  */

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Andrew Cagney]

> 2003-06-11  Jim Blandy  <jimb@redhat.com>
> 
> 	* gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method.
> 	* arch-utils.c (generic_bfd_entry_point): New function.
> 	* arch-utils.h (generic_bfd_entry_point): New declaration.
> 	* gdbarch.c, gdbarch.h: Regenerated.
> 	* solib-svr4.c (enable_break): Call it, instead of accessing
> 	tmp_bfd->start_address directly.
>   
I think this should be in BFD.  Not just GDB but also the simulators are 
going to need this information.

Andrew

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Andrew Cagney]

> 2003-06-11  Jim Blandy  <jimb@redhat.com>
> 
>     * gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method.
>     * arch-utils.c (generic_bfd_entry_point): New function.
>     * arch-utils.h (generic_bfd_entry_point): New declaration.
>     * gdbarch.c, gdbarch.h: Regenerated.
>     * solib-svr4.c (enable_break): Call it, instead of accessing
>     tmp_bfd->start_address directly.
>   I think this should be in BFD.  Not just GDB but also the simulators are going to need this information.

PS: If BFD does this, ENTRY_POINT_ADDRESS can also, finally, be deleted.

Andrew

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:

> > 2003-06-11  Jim Blandy  <jimb@redhat.com>
> > 	* gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method.
> > 	* arch-utils.c (generic_bfd_entry_point): New function.
> > 	* arch-utils.h (generic_bfd_entry_point): New declaration.
> > 	* gdbarch.c, gdbarch.h: Regenerated.
> > 	* solib-svr4.c (enable_break): Call it, instead of accessing
> > 	tmp_bfd->start_address directly.
> >
> I think this should be in BFD.  Not just GDB but also the simulators
> are going to need this information.

Not sure I agree.  The interesting information for process startup is
intrinsically ABI-specific; for PPC64 Linux it's the TOC and
environment pointers, but for another target it might be something
else.  You need ABI-specific code on the consumer's side anyway, just
to know, for example, which registers everything goes in, so as long
as that's there anyway, why not let BFD stick to what it does best ---
interpreting object files?

In general, the code in GDB supporting an ABI needs to be able to
provide its own code to interpret what comes out of BFD.  This is just
one case that wasn't covered --- thus the gdbarch method.

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Andrew Cagney]

> Andrew Cagney <ac131313@redhat.com> writes:
> 
> 
>> > 2003-06-11  Jim Blandy  <jimb@redhat.com>
>> > 	* gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method.
>> > 	* arch-utils.c (generic_bfd_entry_point): New function.
>> > 	* arch-utils.h (generic_bfd_entry_point): New declaration.
>> > 	* gdbarch.c, gdbarch.h: Regenerated.
>> > 	* solib-svr4.c (enable_break): Call it, instead of accessing
>> > 	tmp_bfd->start_address directly.
>> >
> 
>> I think this should be in BFD.  Not just GDB but also the simulators
>> are going to need this information.
> 
> 
> Not sure I agree.  The interesting information for process startup is
> intrinsically ABI-specific; for PPC64 Linux it's the TOC and
> environment pointers, but for another target it might be something
> else.  You need ABI-specific code on the consumer's side anyway, just
> to know, for example, which registers everything goes in, so as long
> as that's there anyway, why not let BFD stick to what it does best ---
> interpreting object files?

not forgettting architecture, disassembler, minimal symbols, ...

> In general, the code in GDB supporting an ABI needs to be able to
> provide its own code to interpret what comes out of BFD.  This is just
> one case that wasn't covered --- thus the gdbarch method.

 From my PS:

>   I think this should be in BFD.  Not just GDB but also the simulators are going to need this information.
> 
> PS: If BFD does this, ENTRY_POINT_ADDRESS can also, finally, be deleted.

The above and CALL_DUMMY_ADDRESS are effecively doing the same thing - 
returning the entry-point address.  If nothing else, some juggling will 
let them share a common architecture method and avoid this duplication.

Anyway, I still think it's better to have it available in bfd (where the 
sim can use it).

Andrew

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Kevin Buettner]

On Jun 11,  8:22am, Jim Blandy wrote:
> Subject: [ppc64-linux] gdbarch hook to find true execution entry point
> 
> 2003-06-11  Jim Blandy  <jimb@redhat.com>
> 
> 	* gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method.
> 	* arch-utils.c (generic_bfd_entry_point): New function.
> 	* arch-utils.h (generic_bfd_entry_point): New declaration.
> 	* gdbarch.c, gdbarch.h: Regenerated.
> 	* solib-svr4.c (enable_break): Call it, instead of accessing
> 	tmp_bfd->start_address directly.
>   
[...]
> Index: gdb/solib-svr4.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/solib-svr4.c,v
> retrieving revision 1.32.8.2
> diff -c -r1.32.8.2 solib-svr4.c
> *** gdb/solib-svr4.c	11 Jun 2003 13:00:34 -0000	1.32.8.2
> --- gdb/solib-svr4.c	11 Jun 2003 13:16:32 -0000
> ***************
> *** 1022,1028 ****
>   	 the current pc (which should point at the entry point for the
>   	 dynamic linker) and subtracting the offset of the entry point.  */
>         if (!load_addr_found)
> ! 	load_addr = read_pc () - tmp_bfd->start_address;
>   
>         /* Record the relocated start and end address of the dynamic linker
>            text and plt section for svr4_in_dynsym_resolve_code.  */
> --- 1022,1029 ----
>   	 the current pc (which should point at the entry point for the
>   	 dynamic linker) and subtracting the offset of the entry point.  */
>         if (!load_addr_found)
> ! 	load_addr = (read_pc ()
> !                      - generic_bfd_entry_point (current_gdbarch, tmp_bfd));
>   
>         /* Record the relocated start and end address of the dynamic linker
>            text and plt section for svr4_in_dynsym_resolve_code.  */

Shouldn't enable_break() in solib-svr4.c be calling
gdbarch_bfd_entry_point()?

What cases do you know of where calling bfd_get_start_address() is
insufficient for finding the start address?  I'm wondering if we
need a gdbarch hook at all...

Kevin

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Jim Blandy]

Kevin Buettner <kevinb@redhat.com> writes:
> On Jun 11,  8:22am, Jim Blandy wrote:
> > Subject: [ppc64-linux] gdbarch hook to find true execution entry point
> > 
> > 2003-06-11  Jim Blandy  <jimb@redhat.com>
> > 
> > 	* gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method.
> > 	* arch-utils.c (generic_bfd_entry_point): New function.
> > 	* arch-utils.h (generic_bfd_entry_point): New declaration.
> > 	* gdbarch.c, gdbarch.h: Regenerated.
> > 	* solib-svr4.c (enable_break): Call it, instead of accessing
> > 	tmp_bfd->start_address directly.
> >   
> [...]
> > Index: gdb/solib-svr4.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/solib-svr4.c,v
> > retrieving revision 1.32.8.2
> > diff -c -r1.32.8.2 solib-svr4.c
> > *** gdb/solib-svr4.c	11 Jun 2003 13:00:34 -0000	1.32.8.2
> > --- gdb/solib-svr4.c	11 Jun 2003 13:16:32 -0000
> > ***************
> > *** 1022,1028 ****
> >   	 the current pc (which should point at the entry point for the
> >   	 dynamic linker) and subtracting the offset of the entry point.  */
> >         if (!load_addr_found)
> > ! 	load_addr = read_pc () - tmp_bfd->start_address;
> >   
> >         /* Record the relocated start and end address of the dynamic linker
> >            text and plt section for svr4_in_dynsym_resolve_code.  */
> > --- 1022,1029 ----
> >   	 the current pc (which should point at the entry point for the
> >   	 dynamic linker) and subtracting the offset of the entry point.  */
> >         if (!load_addr_found)
> > ! 	load_addr = (read_pc ()
> > !                      - generic_bfd_entry_point (current_gdbarch, tmp_bfd));
> >   
> >         /* Record the relocated start and end address of the dynamic linker
> >            text and plt section for svr4_in_dynsym_resolve_code.  */
> 
> Shouldn't enable_break() in solib-svr4.c be calling
> gdbarch_bfd_entry_point()?

Actually, the overhead of the indirect function call would be a
serious performance problem here.  And since using any target other
than PPC64 indicates major pilot error to begin with, I think it's
better that we catch that problem early by having GDB fail at this
point than just paper over the problem by allowing other targets to
function properly.  Allowing GDB to run "correctly" on those systems
only creates the illusion that they are adequate for real work.

(Um, yes, thanks for catching that.)

> What cases do you know of where calling bfd_get_start_address() is
> insufficient for finding the start address?  I'm wondering if we
> need a gdbarch hook at all...

The comment on the gdbarch.sh entry is supposed to explain why it's
necessary.  I've expanded it a bit; is it clearer?  Is there someplace
else I should put it?

+ # The actual instruction address at which ABFD would begin execution.
+ # If ABFD is position-independent code, this address is not relocated;
+ # it's the address at which execution would begin if the file were
+ # loaded at its sections' vmas.
+ # 
+ # On most architectures, this is simply bfd_get_start_address.  But on
+ # some (like 64-bit PPC), that points to a function descriptor, not an
+ # instruction.  The descriptor contains the actual entry point, and
+ # other pointers needed to call the function.
+ m:1::CORE_ADDR:bfd_entry_point:bfd *abfd:abfd:::generic_bfd_entry_point::0

Revised patch:

2003-06-11  Jim Blandy  <jimb@redhat.com>

	* gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method.
	* arch-utils.c (generic_bfd_entry_point): New function.
	* arch-utils.h (generic_bfd_entry_point): New declaration.
	* gdbarch.c, gdbarch.h: Regenerated.
	* solib-svr4.c (enable_break): Call it, instead of accessing
	tmp_bfd->start_address directly.
  
Index: gdb/gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.247
diff -c -r1.247 gdbarch.sh
*** gdb/gdbarch.sh	13 Jun 2003 04:40:32 -0000	1.247
--- gdb/gdbarch.sh	13 Jun 2003 22:29:35 -0000
***************
*** 666,671 ****
--- 666,681 ----
  f:2:TARGET_PRINT_INSN:int:print_insn:bfd_vma vma, disassemble_info *info:vma, info:::legacy_print_insn::0
  f:2:SKIP_TRAMPOLINE_CODE:CORE_ADDR:skip_trampoline_code:CORE_ADDR pc:pc:::generic_skip_trampoline_code::0
  
+ # The actual instruction address at which ABFD would begin execution.
+ # If ABFD is position-independent code, this address is not relocated;
+ # it's the address at which execution would begin if the file were
+ # loaded at its sections' vmas.
+ # 
+ # On most architectures, this is simply bfd_get_start_address.  But on
+ # some (like 64-bit PPC), that points to a function descriptor, not an
+ # instruction.  The descriptor contains the actual entry point, and
+ # other pointers needed to call the function.
+ m:1::CORE_ADDR:bfd_entry_point:bfd *abfd:abfd:::generic_bfd_entry_point::0
  
  # For SVR4 shared libraries, each call goes through a small piece of
  # trampoline code in the ".plt" section.  IN_SOLIB_CALL_TRAMPOLINE evaluates
Index: gdb/arch-utils.c
===================================================================
RCS file: /cvs/src/src/gdb/arch-utils.c,v
retrieving revision 1.87
diff -c -r1.87 arch-utils.c
*** gdb/arch-utils.c	12 Jun 2003 23:25:37 -0000	1.87
--- gdb/arch-utils.c	13 Jun 2003 22:29:29 -0000
***************
*** 368,373 ****
--- 368,379 ----
    return 0;
  }
  
+ CORE_ADDR
+ generic_bfd_entry_point (struct gdbarch *gdbarch, bfd *abfd)
+ {
+   return bfd_get_start_address (abfd);
+ }
+ 
  /* Legacy version of target_virtual_frame_pointer().  Assumes that
     there is an DEPRECATED_FP_REGNUM and that it is the same, cooked or
     raw.  */
Index: gdb/arch-utils.h
===================================================================
RCS file: /cvs/src/src/gdb/arch-utils.h,v
retrieving revision 1.49
diff -c -r1.49 arch-utils.h
*** gdb/arch-utils.h	12 Jun 2003 23:25:37 -0000	1.49
--- gdb/arch-utils.h	13 Jun 2003 22:29:30 -0000
***************
*** 81,86 ****
--- 81,90 ----
  extern const struct floatformat *default_float_format (struct gdbarch *gdbarch);
  extern const struct floatformat *default_double_format (struct gdbarch *gdbarch);
  
+ /* Return the start address of ABFD.  This is exactly like
+    bfd_get_start_address, except that it's a gdbarch function.  */
+ extern CORE_ADDR generic_bfd_entry_point (struct gdbarch *gdbarch, bfd *abfd);
+ 
  /* The following DEPRECATED interfaces are for pre- multi-arch legacy
     targets. */
  
Index: gdb/solib-svr4.c
===================================================================
RCS file: /cvs/src/src/gdb/solib-svr4.c,v
retrieving revision 1.35
diff -c -r1.35 solib-svr4.c
*** gdb/solib-svr4.c	13 Jun 2003 21:56:27 -0000	1.35
--- gdb/solib-svr4.c	13 Jun 2003 22:29:36 -0000
***************
*** 1036,1042 ****
  	 the current pc (which should point at the entry point for the
  	 dynamic linker) and subtracting the offset of the entry point.  */
        if (!load_addr_found)
! 	load_addr = read_pc () - tmp_bfd->start_address;
  
        /* Record the relocated start and end address of the dynamic linker
           text and plt section for svr4_in_dynsym_resolve_code.  */
--- 1036,1043 ----
  	 the current pc (which should point at the entry point for the
  	 dynamic linker) and subtracting the offset of the entry point.  */
        if (!load_addr_found)
! 	load_addr = (read_pc ()
!                      - gdbarch_bfd_entry_point (current_gdbarch, tmp_bfd));
  
        /* Record the relocated start and end address of the dynamic linker
           text and plt section for svr4_in_dynsym_resolve_code.  */
Index: gdb/gdbarch.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.c,v
retrieving revision 1.225
diff -c -r1.225 gdbarch.c
*** gdb/gdbarch.c	13 Jun 2003 04:40:31 -0000	1.225
--- gdb/gdbarch.c	13 Jun 2003 22:29:32 -0000
***************
*** 264,269 ****
--- 264,270 ----
    gdbarch_software_single_step_ftype *software_single_step;
    gdbarch_print_insn_ftype *print_insn;
    gdbarch_skip_trampoline_code_ftype *skip_trampoline_code;
+   gdbarch_bfd_entry_point_ftype *bfd_entry_point;
    gdbarch_in_solib_call_trampoline_ftype *in_solib_call_trampoline;
    gdbarch_in_solib_return_trampoline_ftype *in_solib_return_trampoline;
    gdbarch_pc_in_sigtramp_ftype *pc_in_sigtramp;
***************
*** 432,437 ****
--- 433,439 ----
    0,  /* software_single_step */
    0,  /* print_insn */
    0,  /* skip_trampoline_code */
+   generic_bfd_entry_point,  /* bfd_entry_point */
    0,  /* in_solib_call_trampoline */
    0,  /* in_solib_return_trampoline */
    0,  /* pc_in_sigtramp */
***************
*** 557,562 ****
--- 559,565 ----
    current_gdbarch->smash_text_address = core_addr_identity;
    current_gdbarch->print_insn = legacy_print_insn;
    current_gdbarch->skip_trampoline_code = generic_skip_trampoline_code;
+   current_gdbarch->bfd_entry_point = generic_bfd_entry_point;
    current_gdbarch->in_solib_call_trampoline = generic_in_solib_call_trampoline;
    current_gdbarch->in_solib_return_trampoline = generic_in_solib_return_trampoline;
    current_gdbarch->pc_in_sigtramp = legacy_pc_in_sigtramp;
***************
*** 746,751 ****
--- 749,755 ----
    /* Skip verify of software_single_step, has predicate */
    /* Skip verify of print_insn, invalid_p == 0 */
    /* Skip verify of skip_trampoline_code, invalid_p == 0 */
+   /* Skip verify of bfd_entry_point, invalid_p == 0 */
    /* Skip verify of in_solib_call_trampoline, invalid_p == 0 */
    /* Skip verify of in_solib_return_trampoline, invalid_p == 0 */
    /* Skip verify of pc_in_sigtramp, invalid_p == 0 */
***************
*** 790,795 ****
--- 794,803 ----
                        GDB_MULTI_ARCH);
    if (GDB_MULTI_ARCH)
      fprintf_unfiltered (file,
+                         "gdbarch_dump: bfd_entry_point = 0x%08lx\n",
+                         (long) current_gdbarch->bfd_entry_point);
+   if (GDB_MULTI_ARCH)
+     fprintf_unfiltered (file,
                          "gdbarch_dump: gdbarch_frame_align_p() = %d\n",
                          gdbarch_frame_align_p (current_gdbarch));
    if (GDB_MULTI_ARCH)
***************
*** 5434,5439 ****
--- 5442,5466 ----
                                    gdbarch_skip_trampoline_code_ftype skip_trampoline_code)
  {
    gdbarch->skip_trampoline_code = skip_trampoline_code;
+ }
+ 
+ CORE_ADDR
+ gdbarch_bfd_entry_point (struct gdbarch *gdbarch, bfd *abfd)
+ {
+   gdb_assert (gdbarch != NULL);
+   if (gdbarch->bfd_entry_point == 0)
+     internal_error (__FILE__, __LINE__,
+                     "gdbarch: gdbarch_bfd_entry_point invalid");
+   if (gdbarch_debug >= 2)
+     fprintf_unfiltered (gdb_stdlog, "gdbarch_bfd_entry_point called\n");
+   return gdbarch->bfd_entry_point (gdbarch, abfd);
+ }
+ 
+ void
+ set_gdbarch_bfd_entry_point (struct gdbarch *gdbarch,
+                              gdbarch_bfd_entry_point_ftype bfd_entry_point)
+ {
+   gdbarch->bfd_entry_point = bfd_entry_point;
  }
  
  int
Index: gdb/gdbarch.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.h,v
retrieving revision 1.194
diff -c -r1.194 gdbarch.h
*** gdb/gdbarch.h	13 Jun 2003 04:40:32 -0000	1.194
--- gdb/gdbarch.h	13 Jun 2003 22:29:33 -0000
***************
*** 2699,2704 ****
--- 2699,2718 ----
  #define SKIP_TRAMPOLINE_CODE(pc) (gdbarch_skip_trampoline_code (current_gdbarch, pc))
  #endif
  
+ /* The actual instruction address at which ABFD would begin execution.
+    If ABFD is position-independent code, this address is not relocated;
+    it's the address at which execution would begin if the file were
+    loaded at its sections' vmas.
+   
+    On most architectures, this is simply bfd_get_start_address.  But on
+    some (like 64-bit PPC), that points to a function descriptor, not an
+    instruction.  The descriptor contains the actual entry point, and
+    other pointers needed to call the function. */
+ 
+ typedef CORE_ADDR (gdbarch_bfd_entry_point_ftype) (struct gdbarch *gdbarch, bfd *abfd);
+ extern CORE_ADDR gdbarch_bfd_entry_point (struct gdbarch *gdbarch, bfd *abfd);
+ extern void set_gdbarch_bfd_entry_point (struct gdbarch *gdbarch, gdbarch_bfd_entry_point_ftype *bfd_entry_point);
+ 
  /* For SVR4 shared libraries, each call goes through a small piece of
     trampoline code in the ".plt" section.  IN_SOLIB_CALL_TRAMPOLINE evaluates
     to nonzero if we are currently stopped in one of these. */

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Kevin Buettner]

On Jun 13,  5:32pm, Jim Blandy wrote:

> > What cases do you know of where calling bfd_get_start_address() is
> > insufficient for finding the start address?  I'm wondering if we
> > need a gdbarch hook at all...
> 
> The comment on the gdbarch.sh entry is supposed to explain why it's
> necessary.  I've expanded it a bit; is it clearer?  Is there someplace
> else I should put it?

I probably missed the comment in your original patch.  But what you
wrote below looks good to me.

> + # The actual instruction address at which ABFD would begin execution.
> + # If ABFD is position-independent code, this address is not relocated;
> + # it's the address at which execution would begin if the file were
> + # loaded at its sections' vmas.
> + # 
> + # On most architectures, this is simply bfd_get_start_address.  But on
> + # some (like 64-bit PPC), that points to a function descriptor, not an
> + # instruction.  The descriptor contains the actual entry point, and
> + # other pointers needed to call the function.
> + m:1::CORE_ADDR:bfd_entry_point:bfd *abfd:abfd:::generic_bfd_entry_point::0
> 
> Revised patch:
> 
> 2003-06-11  Jim Blandy  <jimb@redhat.com>
> 
> 	* gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method.
> 	* arch-utils.c (generic_bfd_entry_point): New function.
> 	* arch-utils.h (generic_bfd_entry_point): New declaration.
> 	* gdbarch.c, gdbarch.h: Regenerated.
> 	* solib-svr4.c (enable_break): Call it, instead of accessing
> 	tmp_bfd->start_address directly.

The solib-svr4.c change is okay with me.  If you can get Andrew on board
for the gdbarch changes, you're good to go.  If you wind up implementing
it in bfd, consider the solib change to be pre-approved.

Kevin

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Andrew Cagney]

> 2003-06-11  Jim Blandy  <jimb@redhat.com>
>> 
>> 	* gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method.
>> 	* arch-utils.c (generic_bfd_entry_point): New function.
>> 	* arch-utils.h (generic_bfd_entry_point): New declaration.
>> 	* gdbarch.c, gdbarch.h: Regenerated.
>> 	* solib-svr4.c (enable_break): Call it, instead of accessing
>> 	tmp_bfd->start_address directly.
> 
> 
> The solib-svr4.c change is okay with me.  If you can get Andrew on board
> for the gdbarch changes, you're good to go.  If you wind up implementing
> it in bfd, consider the solib change to be pre-approved.

I'm still struggling to differentiate gdbarch_bfd_entry_point, 
entry_point_address(), CALL_DUMMY_ADDRESS, and now 
CONVERT_FROM_FUNC_PTR_ADDR.

I need to re-read the threads.

(And I've even got the original PowerOpen spec at home!)

Andrew

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Andrew Cagney]

>> > --- 1022,1029 ----
>> >   	 the current pc (which should point at the entry point for the
>> >   	 dynamic linker) and subtracting the offset of the entry point.  */
>> >         if (!load_addr_found)
>> > ! 	load_addr = (read_pc ()
>> > !                      - generic_bfd_entry_point (current_gdbarch, tmp_bfd));
>> >   
>> >         /* Record the relocated start and end address of the dynamic linker
>> >            text and plt section for svr4_in_dynsym_resolve_code.  */
> 
>> 
>> Shouldn't enable_break() in solib-svr4.c be calling
>> gdbarch_bfd_entry_point()?
> 
> 
> Actually, the overhead of the indirect function call would be a
> serious performance problem here.  And since using any target other
> than PPC64 indicates major pilot error to begin with, I think it's
> better that we catch that problem early by having GDB fail at this
> point than just paper over the problem by allowing other targets to
> function properly.  Allowing GDB to run "correctly" on those systems
> only creates the illusion that they are adequate for real work.

Um, I don't understand this paragraph at all.  Which `indirect function 
call would be a serious performance problem here'?

> (Um, yes, thanks for catching that.)
> 
> 
>> What cases do you know of where calling bfd_get_start_address() is
>> insufficient for finding the start address?  I'm wondering if we
>> need a gdbarch hook at all...
> 
> 
> The comment on the gdbarch.sh entry is supposed to explain why it's
> necessary.  I've expanded it a bit; is it clearer?  Is there someplace
> else I should put it?
> 
> + # The actual instruction address at which ABFD would begin execution.
> + # If ABFD is position-independent code, this address is not relocated;
> + # it's the address at which execution would begin if the file were
> + # loaded at its sections' vmas.
> + # 
> + # On most architectures, this is simply bfd_get_start_address.  But on
> + # some (like 64-bit PPC), that points to a function descriptor, not an
> + # instruction.  The descriptor contains the actual entry point, and
> + # other pointers needed to call the function.
> + m:1::CORE_ADDR:bfd_entry_point:bfd *abfd:abfd:::generic_bfd_entry_point::0

So, given a function descriptor at VMA bfd_get_start_address(), there 
are two possible code addresses:

- The relocated address found by reading the descriptor from the target.
This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), target memory)?

- The un-relocated address found by reading the descriptor from the bfd.
This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), use bfd 
memory)?

and the two values are different.  Hence the new method.

Several things I'm still missing though:

- Is entry_point_address wrong?
"symfile.c" sets it to bfd_get_start_address() so (ignoring ppc64 
linux), and given an dynamic executable, won't it too need relocating?

- Does svr4_relocate_main_executable need to be changed?
It is playing with:
   interp_sect = bfd_get_section_by_name (exec_bfd, ".interp");
   if (interp_sect == NULL
       && (bfd_get_file_flags (exec_bfd) & DYNAMIC) != 0
       && bfd_get_start_address (exec_bfd) != pc)
and then:
       displacement = pc - bfd_get_start_address (exec_bfd);
and my understanding of the above suggests that it too needs changing. 
Hmm, interp_sect is probably non-NULL so the test would fail, but for 
consistency?

- Can infcall.c instead explicitly call CONVERT_FROM_FUNC_PTR_ADDR on 
CALL_DUMMY_ADDRESS, or better, have entry_point_address do this?  It 
would help eliminate CALL_DUMMY_ADDRESS.

Andrew

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:
> > + # The actual instruction address at which ABFD would begin
> > execution.
> > + # If ABFD is position-independent code, this address is not relocated;
> > + # it's the address at which execution would begin if the file were
> > + # loaded at its sections' vmas.
> > + # + # On most architectures, this is simply bfd_get_start_address.
> > But on
> > + # some (like 64-bit PPC), that points to a function descriptor, not an
> > + # instruction.  The descriptor contains the actual entry point, and
> > + # other pointers needed to call the function.
> > + m:1::CORE_ADDR:bfd_entry_point:bfd *abfd:abfd:::generic_bfd_entry_point::0
> 
> So, given a function descriptor at VMA bfd_get_start_address(), there
> are two possible code addresses:
> 
> - The relocated address found by reading the descriptor from the target.
> This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), target memory)?
> 
> - The un-relocated address found by reading the descriptor from the bfd.
> This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), use bfd
> memory)?
> 
> and the two values are different.  Hence the new method.

That's the important difference, yes.  The trick the solib code uses
to find the dynamic linker's load offset really does need the
unrelocated address --- the amount by which it would need to be
relocated is exactly what we're computing there.

> Several things I'm still missing though:
> 
> - Is entry_point_address wrong?
> "symfile.c" sets it to bfd_get_start_address() so (ignoring ppc64
> linux), and given an dynamic executable, won't it too need
> relocating?

Yes, it will need relocation.  Executables always used to load at
fixed addresses; now they're becoming relocatable to make
buffer-overflow attacks harder.  So this is a new issue.

> - Does svr4_relocate_main_executable need to be changed?
> It is playing with:
>    interp_sect = bfd_get_section_by_name (exec_bfd, ".interp");
>    if (interp_sect == NULL
>        && (bfd_get_file_flags (exec_bfd) & DYNAMIC) != 0
>        && bfd_get_start_address (exec_bfd) != pc)
> and then:
>        displacement = pc - bfd_get_start_address (exec_bfd);
> and my understanding of the above suggests that it too needs
> changing. Hmm, interp_sect is probably non-NULL so the test would
> fail, but for consistency?

Yes, that should call gdbarch_bfd_entry_point too --- thanks for
catching that.

> - Can infcall.c instead explicitly call CONVERT_FROM_FUNC_PTR_ADDR on
> CALL_DUMMY_ADDRESS, or better, have entry_point_address do this?  It
> would help eliminate CALL_DUMMY_ADDRESS.

I'm not sure I understand enough of the details to say anything about
this.  Why isn't infcall.c just using entry_point_address right now?

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Andrew Cagney]

> - Can infcall.c instead explicitly call CONVERT_FROM_FUNC_PTR_ADDR on
>> CALL_DUMMY_ADDRESS, or better, have entry_point_address do this?  It
>> would help eliminate CALL_DUMMY_ADDRESS.
> 
> 
> I'm not sure I understand enough of the details to say anything about
> this.  Why isn't infcall.c just using entry_point_address right now?

Unfortunatly, a number of targets, such as PowerPC 64 GNU/Linux, have 
added custom CALL_DUMMY_ADDRESS methods :-(

My original concern here was that CALL_DUMMY_ADDRESS, 
CONVERT_FROM_FUNC_PTR_ADDR, and this new architecture method all 
appeared to be doing roughly the same thing.

Can at PowerPC 64 GNU/Linux's CALL_DUMMY_ADDRESS be eliminated?

> So, given a function descriptor at VMA bfd_get_start_address(), there
>> are two possible code addresses:
>> 
>> - The relocated address found by reading the descriptor from the target.
>> This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), target memory)?
>> 
>> - The un-relocated address found by reading the descriptor from the bfd.
>> This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), use bfd
>> memory)?
>> 
>> and the two values are different.  Hence the new method.
> 
> 
> That's the important difference, yes.  The trick the solib code uses
> to find the dynamic linker's load offset really does need the
> unrelocated address --- the amount by which it would need to be
> relocated is exactly what we're computing there.

So technically, CONVERT_FROM_FUNC_PTR_ADDR should be modified to take a 
memory accessor method (bfd or the target).  That would require a major 
target stack overhaul though, outch :-(

This leaves either GDB or BFD needing this method.  I guess, for the 
moment, GDB gets it, but can it at least be called something meaningful?

A guess is CONVERT_FROM_BFD_CODE_PTR_ADDR(entry_point, bfd)?  Better? 
ENTRY_POINT_FROM_BFD? (I believe FUNC in the above should have been CODE?).

Your also going to need documentation.

Andrew

Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Andrew Cagney]

>>> - Can infcall.c instead explicitly call CONVERT_FROM_FUNC_PTR_ADDR on
>>> CALL_DUMMY_ADDRESS, or better, have entry_point_address do this?  It
>>> would help eliminate CALL_DUMMY_ADDRESS.
>>> 

>> 
>> I'm not sure I understand enough of the details to say anything about
>> this.  Why isn't infcall.c just using entry_point_address right now?
>> 

> Unfortunatly, a number of targets, such as PowerPC 64 GNU/Linux, have added custom CALL_DUMMY_ADDRESS methods :-(
> 
> My original concern here was that CALL_DUMMY_ADDRESS, CONVERT_FROM_FUNC_PTR_ADDR, and this new architecture method all appeared to be doing roughly the same thing.
> 
> Can at PowerPC 64 GNU/Linux's CALL_DUMMY_ADDRESS be eliminated?

Just FYI, I've eliminated CALL_DUMMY_ADDRESS.

Andrew