Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions)

[Paul Schlie]

Unless I'm mistaken, all values transmitted across the link are independent
of endian-ness, as they are serialized as a logical sequence of ascii
encoded hex characters from significant logical nibble first to least
significant, independently of host/client platform's endian-ness;
correspondingly a shift operation in C arithmetically/logically shifts the
value of an integer transparently of it's storage format, so I don't
understand why you think you need to do what you've done? Can you give an
example?

Thanks, -paul-

> From: "Theodore A. Roth" <address@hidden>
> Date: Tue, 19 Oct 2004 13:37:49 -0700 (PDT)
> To: Paul Schlie <address@hidden>
> Cc: Frost_Tobias <address@hidden>, <address@hidden>
> Subject: Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu
> m(...) bug fix (for more recent gdb versions)
> 
> On Tue, 19 Oct 2004, Paul Schlie wrote:
> 
>> num is an integer, not a string, hex nibbles are 4 bit's wide,
>> hence to build an integer out of a sequence of hex-chars->nibbles
>> one shifts the integer by 4.
>> 
>> 
>>> From: Frost_Tobias <address@hidden>
>>> Date: Tue, 19 Oct 2004 09:13:37 +0200
>>> To: <address@hidden>
>>> Subject: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu
>>> m(...) bug fix (for more recent gdb versions)
>>> 
>>> No, the patch's correct.
>>> Num will be shifted by 4 every time the while is executed and then stored.
>>> Then the low nibble will be ored into num
> 
> Actually, the patch is only partially correct. It does consider the fact
> that the multi-byte value for the register number is in little endian
> format.
> 
> Yes, the "<< (1 * 4)" part is very wrong.
> 
> Attached is a patch to fix gdb_extract_hex_num() to match up with what
> today's cvs version of gdb is doing. With this change, I was able to
> using the old C simulavr code with the latest gdb to step through a
> program.
> 
> Unfortunately, I found a bug in gdb that breaks the "load" command. I've
> already sent a patch for that to the gdb folks though.
> 
>>> 
>>> Example:
>>> 
>>> *p = ABCDEF
>>> 
>>> will be: (each line is one while-execution)
>>> 
>>>     num
>>> 0x0000 000A
>>> 0x0000 00AB
>>> 0x0000 0ABC
>>> 0x0000 ABCD
>>> 0x000A BCDE
>>> 0x00AB CDEF
>>> 
>>>  num = (num << (i * 4)) | hex2nib (*p);  (replaced by following line) */
> 
> Yes. The above is broken. Don't know what I was thinking when I wrote
> that.
> 
> For your example, the final result should really be this:
> 
>   0x00EF_CDAB
> 
> 
> ---
> Ted Roth
> PGP Key ID: 0x18F846E9
> Jabber ID: address@hidden