This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]