PATCH: error reading variable: value has been optimized out

[Jan Kratochvil]

On Tue, 04 Sep 2012 18:57:41 +0200, Andrew Burgess wrote:
> On 03/09/2012 4:16 PM, Jan Kratochvil wrote:
> > ABI registers order: rdi rsi rdx rcx r8 r9
> > ==amd64_dummy_call_integer_regs
> 
> You're correct that what I originally wrote was not correct, but I think the
> register ordering used for what was test2, which is the
> extend-into-next-register behaviour, is actually just using the gdb register
> number, so this would be from the enum amd64_regnum.

In my text above I was only following the ABI standard
	http://www.x86-64.org/documentation/abi.pdf
specifically:
	2. If the class is INTEGER, the next available register of the
	sequence %rdi, %rsi, %rdx, %rcx, %r8 and %r9 is used13 .
IIUC this does not mean this hack of register numbers flowing should be used,
it just specifies which registers should be put in DWARF for DW_OP_piece.

In the case the hack of register numbers flowing is used:

For i386 there is:
	i386_register_to_value -> i386_next_regnum
so i386 does not follow GDB numbering but its own one.  During my testcase GDB
(correctly for GCC) composed HIGH(%edx==gdb reg. #2) | LOW(%eax==gdb reg. #0).
as i386_next_regnum (%eax==gdb reg. #0) == %edx==gdb reg. #2.

For amd64 the target code does not do anything specific so it is processed in
read_frame_register_value and it really follows the GDB registers numbering.
But that seems wrong to me as it violates the ABI specification above.
Still it is not being used for anything in real world I think.  An assertion
there does not trigger on GDB testsuite at all.  It would trigger on the AVR
target it was written for
	[RFA/RFC] Restore old handling of multi-register variables
	http://sourceware.org/ml/gdb-patches/2011-10/msg00052.html
but I think that should have been written only to avr-tdep.c with some AVR
registers numbering on mind.

I was unable to produce any such DWARF output (using register numbers flowing)
from any i386/x86_64 GCC compiler here, like FSF 3.4.6, Red Hat 4.1 or FSF
4.4. So I do not think it is of any much concern how multi-register values
behave in read_frame_register_value, except for that AVR compatibility.  It is
also not exploited by your 'bad-bt' testcase. It is exploited by
'struct_param_single_reg_loc' from your new testcase but specifying gdb
numbers of registers there is rather a compatibility with current - assumed
buggy - GDB behavior.


> Any more feedback, or is this ok to commit ?

I am fine with that stating there like:
	This gdb register numbers usage exposed to external DWARF data is more
	a GDB bug and it should be move to target dependent code (such as AVR)
	as a workaround of existing broken DWARF.

Best to keep it here for a week for comments before commit.


Thanks,
Jan