[PATCH][PR breakpoints/16606] AVR8 breakpoint out of range, decrement pc after break

[Pierre Langlois <pierre.langlois@embecosm.com>]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

Firstly, this patch fixes issuing breakpoints using an address 
expression on AVR.

For example:

(gdb) break *0x10e
would result in a breakpoint at the address 0x80010e, out of range.

AVR is an harvard architecture and we use the top bits of the internal 
addresses to determine whether this is a code address or a data address. 
In this case, 0x800000 was applied to this address because it was 
considered to be a data address. A more detailed explanation of this 
behaviour can be found on bugzilla: 
https://sourceware.org/bugzilla/show_bug.cgi?id=16606#c1

When returning a struct value from the evaluation of *0x10e, nothing in 
this value indicates that it resides in code space. In this case the 
expression is a linespec, referring to source code, so we can safely 
assume the address is in code space. We can set the TYPE_CODE_SPACE 
instance flag on the type of the value. When the value is converted to 
an address, gdbarch_integer_to_address can apply the correct mask 
depending on TYPE_CODE_SPACE.

This fix unveiled another issue, the program counter was not decremented 
after hitting the breakpoint instruction.
This patch fixes this by adding gdbarch_decr_pc_after_break to AVR's 
gdbarch.

Best,

Pierre


[-- Attachment #2: pr-breakpoint-16606.patch --]
[-- Type: text/x-patch, Size: 1967 bytes --]

diff --git a/gdb/avr-tdep.c b/gdb/avr-tdep.c
index 6e58f04..a4a4a6d 100644
--- a/gdb/avr-tdep.c
+++ b/gdb/avr-tdep.c
@@ -333,7 +333,10 @@ avr_integer_to_address (struct gdbarch *gdbarch,
 {
   ULONGEST addr = unpack_long (type, buf);
 
-  return avr_make_saddr (addr);
+  if (TYPE_CODE_SPACE (type))
+    return avr_make_iaddr (addr);
+  else
+    return avr_make_saddr (addr);
 }
 
 static CORE_ADDR
@@ -1436,6 +1439,7 @@ avr_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
   set_gdbarch_inner_than (gdbarch, core_addr_lessthan);
 
   set_gdbarch_breakpoint_from_pc (gdbarch, avr_breakpoint_from_pc);
+  set_gdbarch_decr_pc_after_break (gdbarch, 2);
 
   frame_unwind_append_unwinder (gdbarch, &avr_frame_unwind);
   frame_base_set_default (gdbarch, &avr_frame_base);
diff --git a/gdb/linespec.c b/gdb/linespec.c
index 610809d..8355114 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -2588,6 +2588,7 @@ initialize_defaults (struct symtab **default_symtab, int *default_line)
 static CORE_ADDR
 linespec_expression_to_pc (const char **exp_ptr)
 {
+  struct value *val;
   if (current_program_space->executing_startup)
     /* The error message doesn't really matter, because this case
        should only hit during breakpoint reset.  */
@@ -2595,7 +2596,14 @@ linespec_expression_to_pc (const char **exp_ptr)
 				    "program space is in startup"));
 
   (*exp_ptr)++;
-  return value_as_address (parse_to_comma_and_eval (exp_ptr));
+  val = parse_to_comma_and_eval (exp_ptr);
+  /* The value given by parse_to_comma_and_eval is an address but does not have
+     any information about the address space in which it resides.  Harvard
+     architectures need to know this when converting a value to an address with
+     gdbarch_integer_to_address. It is safe to assume linespecs give an address
+     in code space.  */
+  TYPE_INSTANCE_FLAGS (value_type (val)) |= TYPE_INSTANCE_FLAG_CODE_SPACE;
+  return value_as_address (val);
 }
 
 \f