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

Joel Brobecker
2011-12-27T04:56:45Z

> gcc (GCC) 4.7.0 20111222 (experimental)
> on Fedora Rawhide (pre-17) x86_64 as the function before _start is PLT and
> PLTs have no proper .eh_frame entries. Still such .eh_frame PLT entry sure
> does not apply for the <function called from gdb> frame. Therefore it
> unwinds into garbage and then crashes on it (PC is 0x1 abo-ve).

At first sight, it makes sense to choose the next instruction as
the return address, the same way call instructions do (which is
why unwinders have to subtract 1 from the return address to get
the actual calling instruction).

The situation is a little different in this case, as the function
at the entry point is not actually really the one making the call.
How can we convince ourselves that we are not exchanging one wrong
by another wrong which just happens to work better for the example
at hand? (real question, not rethorical)

> +# It should be at least as maximum of all the supported architectures.
> +V:ULONGEST:max_insn_length:::31:31

Let's take this opportunity to document the unit used for this size
(bytes, right?).

> + /* If the inferior call throws an uncaught C++ exception the inferior
> + unwinder will try to unwind all the frames incl. the dummy frame.
> + Using the entry_point_address directly will try to find FDE at the
> + function right before the entry_point_address address as the
> + unwinder subtracts 1 to get at the call instruction. FDE of the
> + preceding function, if found, would be invalid for the dummy frame
> + and it would crash the inferior's unwinder. Therefore attempt to
> + skip the very first instruction of entry_point_address. */

Minor edit (punctuation and maybe being more explicit on who does what,
and also reformatting to keep it close to 70 chars max - as decided
during one of our discussions):

/* If the inferior call throws an uncaught C++ exception,
the inferior unwinder tries to unwind all frames, including
our dummy frame. The unwinder determines the address of
the calling instruction by subtracting 1 to the return
address. So, using the entry point's address as the return
address would lead the unwinder to use the unwinding
information of the code immediately preceding the entry
point. This information, if found, is invalid for the dummy
frame, and can potentially crash the inferior's unwinder.
Therefore, we try using the second instruction, right
after the one at the entry point's address. */

> + {
> + /* No problem probably occurs without this adjustment. INSN_LEN
> + may be for example larger than the entry_point_address code. */
> + }

/* If we cannot read INSN_LEN bytes (INSN_LEN might be larger
than the entry_point_address code, for instance), it is
probably fine to leave the return address at the entry
point. */

Why would we think that, though? This might be related to may question
at the start of this email...

--
Joel