Re: [PATCH] create_internal_breakpoint: Apply gdbarch_skip_entrypoint.

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Pedro Alves wrote:

> Hmm, not sure.  Are there cases that do want a breakpoint
> on the specific address that was passed down, even if it was
> the entry point address?  I'm looking at the watchpoint scope
> code:
> 
>  	  scope_breakpoint
> 	    = create_internal_breakpoint (frame_unwind_caller_arch (frame),
> 					  frame_unwind_caller_pc (frame),
> 					  bp_watchpoint_scope,
> 					  &momentary_breakpoint_ops);
> 
> and wondering about a signal coming in just while the mainline code
> was going to execute the entry point address.

Hmm, OK.  It probably wouldn't matter in practice, but I agree that
in principle, this usage should not skip to the local entry point.

> I'm particularly thinking of gdbarch_convert_from_func_ptr_addr, and
> wondering why create_overlay_event_breakpoint doesn't need to call it.
> The jit event breakpoint code doesn't call it either, it seems.
> And neither the longjmp even breakpoint, when the breakpoint
> it set by function name instead of by probe.  Are these just cases
> of people not having stumbled on this yet?  Or are these event
> locations/functions different somehow?  Why does the solib-svr4.c
> need to call gdbarch_convert_from_func_ptr_addr for its event
> functions, while others do not?

gdbarch_convert_from_func_ptr_addr pretty much was added whereever
someone noticed that something didn't work on ppc64 ...

In particular, on Linux/ppc64 we don't use overlays; JIT didn't
work for other reasons anyway, same for non-probe longjmp.  The
non-svr4 solib routines aren't used on ppc64.

I agree it would be better to clean this up somehow.

> (or instead move the gdbarch calls to a helper function that given
> an address, returns the function's breakpoint address?)

This sounds reasonable.  Maybe start with an msymbol instead of an
address to make sure this is used only where we have symbol address
to start with?  This is what most users of create_internal_breakpoint
acually do anyway.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com