[PATCH V3] Add negative repeat count to 'x' command

[Simon Marchi]

On 16-05-24 07:16 AM, Pedro Alves wrote:
> On 05/23/2016 06:22 PM, Toshihito Kikuchi wrote:
>> Hi Pedro,
>>
>> Thank you for your kind comments.  Most of them are addressed in next
>> iteration. 
> 
> Great, looking forward.

I think this is an awesome feature.

>>> Also, we should probably be taking into account the addressable
>>> unit size here.
>>
>> Do you mean adding a new parameter like unit_size to pass it to
>> target_read_memory?
>>
> 
> For instance, seems like read_memory_backward assumes that 1 target
> byte fits in 1 host byte, which is not true on e.g., 16-bit byte
> architectures.  But probably easiest is to ignore it for now, and
> then let the tests drive the fixing on such archs as follow ups.
> Simon, what do you think?

Yes, I think you can ignore it for now.  Since I don't think Toshihito has
access to such an architecture, it would be quite difficult to implement it
right without being able to test.

I can take a look at it once it's in.

>>> So in the last test, the address wraps around.  On a non-MMU this will
>>> actually read memory from a high address.  Is this what we want?  Or do
>>> we want to have GDB to never try to go before 0?  Likewise end of addr space.
>>
>> This was my misunderstanding about non-MMU.  I change the expected
>> result, expecting a line starts with '0x\[0-9a-f\]+fd'.
> 
> Similar question with MMU targets though.  Should "x/-1 0" wrap around
> to a high address?  If it does, it should wrap around taking into account
> target address width.  Say, on 32-bit, "0-1" is 0x0..0ffffffff not
> 0xffffffffffffffff, even if gdb to use 64-bits for CORE_ADDR internally.
> Does that work correctly?

Does gdb know what's the upper limit of the address space?

This is also a problem for arches with multiple memory spaces that use the
high bits as address space identifier.  Let's say I do x/-3s from
0x200000040 and it underflows, GDB might try to read from 0x1ffffffd0 for
example, which makes no sense.  I don't know if/how we can avoid it, as
long as we use this hack for representing multiple address spaces in a
single inferior.  Anyway, it's not this patch's fault, so you can certainly
ignore it.