This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH V3] Add negative repeat count to 'x' command
- From: Toshihito Kikuchi <k dot toshihito at yahoo dot de>
- To: Pedro Alves <palves at redhat dot com>, Simon Marchi <simon dot marchi at ericsson dot com>, gdb-patches at sourceware dot org
- Date: Fri, 27 May 2016 10:44:19 -0700
- Subject: Re: [PATCH V3] Add negative repeat count to 'x' command
- Authentication-results: sourceware.org; auth=none
- References: <1461866539-24965-1-git-send-email-k dot toshihito at yahoo dot de> <c2d74e3a-d818-2af2-613e-57ce6bec97f9 at redhat dot com> <57433C3B dot 7000300 at yahoo dot de> <411a982a-a550-a8b7-81f3-7f7ef2aba863 at redhat dot com> <57449708 dot 2060604 at ericsson dot com> <2fa9eff2-8039-3109-eb89-8a019d219078 at redhat dot com>
Thank you for the comments. Let me send an updated patch addressing all
comments except for the behavior of wrapping around address.
>> + else if (format == 's')
>> + {
>> + next_address = find_string_backward (gdbarch, addr, count,
>> + val_type->length,
>
> You could use the TYPE_LENGTH macro.
Updated.
>>>> 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.
OK. Leaving this as is for now.
>>> 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?
>
> There's gdbarch_addr_bit (and gdbarch_ptr_bit).
>
> GDB gets it right if the expressions are done on target pointers:
>
> (gdb) set architecture i386
> The target architecture is assumed to be i386
> (gdb) p ((char*)0)-1
> $1 = 0xffffffff <error: Cannot access memory at address 0xffffffff>
> (gdb) set architecture i386:x86-64
> The target architecture is assumed to be i386:x86-64
> (gdb) p ((char*)0)-1
> $2 = 0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>
I checked the output for i386 target on amd64 machine. From the
observation below, the current test should work fine because it checks
only lower bits of the printed address, though I cannot verify the
memory values since I could not prepare an environment where the address
-1 is accessible. Do you have an idea to create such an environment? I
tried to build a kernel without MMU config, but it was not straightforward.
(gdb) show arch
The target architecture is set automatically (currently i386)
(gdb) x/8xb 0
0x0: 0x48 0x65 0x6c 0x6c 0x6f 0x21 0x00 0x00
(gdb) x/-6xb 3
0xfffffffd: Cannot access memory at address 0xfffffffd
(gdb) x/3xb 0xfffffffffffffffd
0xfffffffd: Cannot access memory at address 0xfffffffd
>> 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.
>
> Yeah.
I see. Leaving this as is as well.
Thanks,
Toshihito