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:

> Might "target" refer to in the link protocol docs mean the target of the
> serial link, which for us is the same machine, as the serial protocol target
> is the simulator process complied and running on the same physical host
> (which it need not be) therefore of the same endian-ness by default,
> although it happens to be pretending to an avr?

I think that would be a valid interpretation of the docs. Normally a
stub runs in the target itself. Simulavr is using a stub in a host app
which translates commands to the target.

Let's wait and see what the gdb gurus have to say on the matter. (I just
sent them an email).

>
>
> > From: Paul Schlie <address@hidden>
> > Date: Tue, 19 Oct 2004 20:53:13 -0400
> > To: "Theodore A. Roth" <address@hidden>
> > Cc: <address@hidden>
> > Subject: Re: AW: [Simulavr-devel] [patch #3453] gdbserver.c 
> > gdb_extract_hex_nu
> > m(...) bug fix (for more recent gdb versions)
> >
> > 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)
> >
> > -paul-
> >
> >
> >> From: "Theodore A. Roth" <address@hidden>
> >> Date: Tue, 19 Oct 2004 17:38:22 -0700 (PDT)
> >> To: Paul Schlie <address@hidden>
> >> Cc: "Theodore A. Roth" <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:
> >>
> >>> The "target byte order" of register DATA, not command strings, etc.
> >>> and likely only relevant when manipulating multi-byte value locations.
> >>>
> >>> I believe that if you simply try my simple fix and print out
> >>> to the error port the result of the integer values received in
> >>> p command requests from gdb, I believe you find things work;
> >>> although acknowledge that squirrelly things remain, as I haven't
> >>> yet been successful in getting everything to work, which may be
> >>> related to endian related en/decoding bugs.
> >>>
> >>> When I run gdb with simulavr with my fix I get with debugging on:
> >>>
> >>> Sending packet: $p0000001e#26...Ack, simulavr: read reg: 30
> >>> Packet received: 0c
> >>> Sending packet: $P1e=0e#b8...Ack
> >>> Packet received: OK
> >>> Sending packet: $p00000022#f4...Ack, simulavr: read reg: 34
> >>> Packet received: 00000000
> >>> Sending packet: $p00000021#f3...Ack, sinulavr: read reg: 33
> >>> Packet received: 0000
> >>> (gdb) print $r30
> >>> Sending packet: $p0000001e#26...Ack, simulavr: read reg: 30
> >>> Packet received: 0e
> >>> $16 = 14 '\016'
> >>> (gdb)
> >>>
> >>> Therefore sense that what you've proposed as a general solution is likely
> >>> incorrect given where and how the function is used in the present code.
> >>>
> >>> But at least I think were looking at the correct issues.
> >>
> >> What version of gdb are you using?
> >>
> >> address@hidden:~/Calendars$ avr-gdb --version
> >> GNU gdb 6.3.50_2004-10-19-cvs
> >> 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=i686-pc-linux-gnu --target=avr".
> >>
> >> It doesn't make any sense to me that you are seeing big-endian 'p'
> >> packets and I'm seeing little-endian. I have this nagging feeeling that
> >> gdb is not doing the right thing. Especially since there's really no
> >> need for the zero padding anyways (we only have 35 registers).
> >>
> >> ---
> >> Ted Roth
> >> PGP Key ID: 0x18F846E9
> >> Jabber ID: address@hidden
> >
> >
> >
> >
> > _______________________________________________
> > Simulavr-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/simulavr-devel
>
>
>
>

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