This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH][PR breakpoints/16606] AVR8 breakpoint out of range, decrement pc after break
- From: Pierre Langlois <pierre dot langlois at embecosm dot com>
- To: gdb-patches at sourceware dot org
- Date: Fri, 07 Mar 2014 19:50:46 +0000
- Subject: [PATCH][PR breakpoints/16606] AVR8 breakpoint out of range, decrement pc after break
- Authentication-results: sourceware.org; auth=none
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
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);
}