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

[Theodore A. Roth]

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

sim-hex-extract.diff
Description: Text document