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

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

> > I just realized that support for multiple address spaces was added
> > but never documented.
> > So the way to solve the issue is to add the @code qualifier as such:
> >
> > (gdb) break * (@code void *) 0x10e
> >
> > And it will set the TYPE_CODE_SPACE instance flag to the type when
> > calling integer_to_address.
> >
> > However, shouldn't @code be the default for breakpoints?
> I am not really sure about that. I know my example is not going to be
> the most frequent situation ever, but what if the code is data memory?
> I admit I didn't know about the @code, is there an equivalent for
> data pointers as well? If that were a yes, I think we could argue
> that indeed, @code would be a better default, and look into what
> it would take to make that happen.
I only just noticed the existence of the space qualifiers. So yes, there are both
@code and @data qualifiers for all targets. We could potentially have @code being
the default and then issuing break *(@data void*) 0xaddr if the architecture
supports executing data memory.

I realized none of these flags are set by default actually, the fact that break defaults
to a data address on AVR is because when evaluating "*0x10e", the resulting value is
given a type with a code TYPE_CODE_INT. The AVR target code interprets this as a data address.

I'm investigating where setting a default address spaces could be implemented.

Thank you for the comments