simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(


From: Theodore A. Roth
Subject: Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c gdb_extract_hex_nu m(...) bug fix (for more recent gdb versions)
Date: Tue, 19 Oct 2004 18:01:07 -0700 (PDT)

On Tue, 19 Oct 2004, Paul Schlie wrote:

> Fully agree something's odd...
>
> [fusion:~] paul% avr-gdb --version
> GNU gdb 6.2.50_20041016
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=powerpc-apple-darwin7.5.0 --target=avr".
>
> (if gdb just branched, that would explain the 6.2/6.3 diff, I believe)

It's a bug in gdb. The 'p' packet was implemented recently (which
explains why the bug in simulavr's gdbserver.c never got tickled):

  
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gdb/remote.c.diff?r1=1.147&r2=1.148&cvsroot=src

You are running on a big-endian system, I'm on a little-endian, thus the
divergence.

The bug in gdb is in fetch_register_using_p(). In particular, this line:

  bin2hex((char *) &regnum, &buf[1], sizeof(regnum));

No attempt has been made to handle endian issues when converting the
value of regnum from binary to a hex string.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]