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

[Pierre Langlois <pierre dot langlois at embecosm dot com>]

Hello,

I'm terribly sorry, I didn't include a Changelog entry to my previous email.

Here it is:

2014-03-10  Pierre Langlois  <pierre.langlois@embecosm.com>

        PR breakpoints/16606:
        * linespec.c (linespec_expression_to_pc): Set
        TYPE_INSTANCE_FLAG_CODE_SPACE to address given by the expression
        parser.
        * avr-tdep.c (avr_integer_to_address): Add TYPE_CODE_SPACE.

Best,

Pierre

On 07/03/14 19:50, Pierre Langlois wrote:
> 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