Re: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3

[Joel Brobecker <brobecker@adacore.com>]

> As ON_STACK is a valid option sure one may prefer to convert all the
> archs to ON_STACK instead of fixing AT_ENTRY_POINT; not preferred by
> me TBH.

I don't understand why, though. ON_STACK seems to be perfect, as
we control exactly what's there, and we know we're not going to
interfere with the rest of the code.

Are there any situation where ON_STACK wouldn't be possible? I know
that on some architectures such as VxWorks, where objfiles are
already loaded in memory, and where memory is shared by all
processes[1], there is no concept of "entry point".

I have put in my TODO list to see if I can get rid of the last
use of AT_SYMBOL (in mips-tdep.c) and convert it to ON_STACK.

> 2011-12-30  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	Fix regression for gdb.cp/gdb2495.exp with gcc-4.7.
> 	* arch-utils.c (displaced_step_at_entry_point): Incrase BP_LEN skip to
> 	3 times.
> 	* infcall.c (call_function_by_hand) <AT_SYMBOL>: Move it upwards and
> 	fall through into AT_ENTRY_POINT.
> 	(call_function_by_hand) <AT_ENTRY_POINT>: New variable bp_len.  Adjust
> 	DUMMY_ADDR with it.
> 	* ppc-linux-tdep.c (ppc_linux_displaced_step_location): Increase
> 	PPC_INSN_SIZE skip to 3 times.

I keep staring at the diff, and I can't figure out how the AT_SYMBOL
case is falling through, or why it would be necessary. The lack of
understading why is probably related to the fact that I may still
have an incorrect understanding of the situation.

I think that either way, it's better to have the dummy calling
address at a location where there is no unwinding information.
ON_STACK seems to be a better place to guaranty that.  But that
being said, making sure that, for AT_ENTRY_POINT, the dummy
calling address is indeed our entry point cannot make things
worse.

>  	    dummy_addr = gdbarch_convert_from_func_ptr_addr (gdbarch,
>  							     dummy_addr,
>  							     &current_target);
> +	    /* A call dummy always consists of just a single breakpoint,
> +	       so it's address is the same as the address of the dummy.  */
                  ^^^
                  its

> +      }
> +      /* FALLTHROUGH */
> +    case AT_ENTRY_POINT:

Is this really a FALLTHROUGH?

> +	   Therefore, we use the second byte (approximately,
> +	   alignments depending on GDBARCH).  It does not matter if it
> +	   is placed inside the very first instruction, nothing tries
> +	   to execute it.  */

I can't remember if you explicitly decided to use the second byte
and then changed your mind, or whether this is a typo from the fact
that the breakpoint instruction on x86 is 1 byte long? Suggest
replacing with:

        Therefore, we adjust the return address by the length
        of a breakpoint, guaranteeing that the unwinder finds
        the correct function as the caller.

-- 
Joel