Re: RDI target broken in 000215 snapshot

[Grant Edwards <grante@visi.com>]

On Fri, Feb 25, 2000 at 03:05:14PM +0000, Fernando Nasser wrote:

> > It's more a question of should the endianess have changed between
> > releases or should it have been little-endian anyway.  Not my problem
> > :-)
> 
> I inherited this one :-)
> 
> But you are right, this will at least require an entry in the
> NEWS, as it alters some previous behavior.  *If* the arm users
> in the list decide that the default should be little-endian.

From what I've seen/read little-endian is more common (does
ARM-Linux run little-endian or big?), and it's the default for
gcc/binutils, so it should probably be the default for gdb as
well.  I was just confused because I thought "auto" meant that it
would be determined by the target.

> It does seem reasonable and if the file command straights it
> out, only the load users would have to care (but they are more
> aware of these issues, and can always have the set endian on
> their .gdbinit).

Having the load command warn the user if the target and file
differ might also be something to consider.

> It is a shame that Angel is so buggy.  The return code should
> appropriately indicate the endianess of the target -- it would
> be a nice feature to use :-(

Does Angel not report it correctly?  The ARM EmbeddedICE is
broken in that respect, but I don't have a copy of Angel
running anywhere.

-- 
Grant Edwards
grante@visi.com
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: gdb@sourceware.cygnus.com
Subject: C++ Overload testsuite fixes, need someone to verify
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <hfdx6o2m.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg00786.html
Content-length: 413

Can someone verify, that i am correct in thinking you get unexpected
failures in gdb.c++/ovldbreak.exp due to "breakpoint info" failures?
I have a patch, i just want to make sure it's not me.
It appears the source line the test suite expects main to appear on
in that file is 49, and main really appears at 48, so the regex to
match doesn't work.  I diffed the ovldbreak.cc file, and i get no
differences.

--Dan
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: annotate.texi
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003070832.DAA14451@indy.delorie.com>
X-SW-Source: 2000-q1/msg00557.html
Content-length: 433

Is there any reason why annotate.texi shouldn't be @include'd by
gdb.texinfo and be part of the manual?  Right now, "set annotate" is
not documented at all, and annotate.texi seems to be just what the
doctor ordered...

And while at that, NEWS seems to be in the need of some work, it
doesn't mention many of the new features that already are in the CVS
tree.  I would like at least to mention the improvements in the DJGPP
version.
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>, gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000224095244.ZM13976@ocotillo.lan>
References: <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local> <Franz.Sirl-kernel@lauterbach.com>
X-SW-Source: 2000-q1/msg00395.html
Content-length: 890

On Feb 22, 11:09pm, Franz Sirl wrote:

> >I invite those of you who have Linux/PPC machines to try out these
> >changes and let me know how they work.  Also, please let me know about
> >any problems that you find.
> 
> I've just uploaded an RPM with the current CVS source to
> ftp://devel.linuxppc.org/users/fsirl/ so people can easily test it.

Thanks.

[...]
> A quick test of gdb looked very promising, I already installed it as the
> default gdb on our build system. What about "info float"? Are you going to
> tackle this yourself later or do you want to leave the implementation to
> somebody else?

If someone else is willing to do the implementation for "info float",
I'm willing to integrate the patches.  (I rarely have need for "info
float", so it may be better if someone else did the implementation.)
OTOH, if no one sends me patches, I'll try to get to it eventually.

Kevin
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: "J.T. Conklin" <jtc@redback.com>
Cc: Stan Shebs <shebs@apple.com>, gdb-patches@sourceware.cygnus.com, GDB <gdb@sourceware.cygnus.com>
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307162127.D485@lucon.org>
References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00576.html
Content-length: 534

On Tue, Mar 07, 2000 at 04:18:23PM -0800, J.T. Conklin wrote:
> >>>>> "hjl" == H J Lu <hjl@valinux.com> writes:
> 
> hjl> 2000-03-07  H.J. Lu  <hjl@gnu.org>
> hjl>
> hjl> 	* gdb-regex.h: New. Include <regex.h> for glibc 2 and include
> hjl> 	"gnu-regex.h" otherwise.
> 
> If we follow the naming convention we have been using, gdb-regex.h

There are gdb-events.c   gdb-events.h   gdb-events.sh  gdb-regex.h
gdb-stabs.h.

> should be gdb_regex.h.

Either way is fine with me. All I want is regex in glibc 2 :-). Any
objections?


H.J.
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: GDB configure problem in the new repository...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A41C50.F4E522DD@netwinder.org>
X-SW-Source: 2000-q1/msg00222.html
Content-length: 1141

Hi,

I checked out a GDB tree on a clean system from the new repository using:

cvs -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co gdb

and attempted to configure using the following directory structure:

cvstree/src
cvstree/gdb-build
cd gdb-build
../src/configure --prefix=/usr 

I get the following error:

checking for Tcl configuration... found /usr/lib/tclConfig.sh
checking for Tk configuration... found /usr/lib/tkConfig.sh
checking for Tcl private headers. dir=unix... checking for tclInt.h... no
configure: error: Can't find Tcl private headers

I checked out the entire tree under src on another machine the other day using
the same setup and I could configure and build with the following results for a
native armv4l-unknown-linux-gnu target on a NetWinder.

                === gdb Summary ===

# of expected passes            6296
# of unexpected failures        56
# of unexpected successes       1
# of expected failures          195
# of unresolved testcases       2
# of untested testcases         5

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From hjl@valinux.com Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: Re: Does today's gdb compile on Linux?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000118104731.B7970@valinux.com>
References: <20000118100532.A7871@valinux.com> <hjl@valinux.com> <1000118184306.ZM1103@ocotillo.lan>
X-SW-Source: 2000-q1/msg00041.html
Content-length: 1621

On Tue, Jan 18, 2000 at 11:43:06AM -0700, Kevin Buettner wrote:
> On Jan 18, 10:05am, H . J . Lu wrote:
> 
> > I cannot get today's gdb in CVS to compile on Linux/ia32. It failed on
> > i386-linux-nat.c:
> > 
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c: In function `supply_fpregset':
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c:215: request for member `st_space' in
> > something not a structure or union
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c:217: request for member `cwd' in
> > something not a structure or union
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c:218: request for member `swd' in
> > something not a structure or union
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c:219: request for member `twd' in
> > something not a structure or union
> > /work/gnu/import/gdb/gdb/i386-linux-nat.c:220: request for member `fip' in
> > 
> > Any ideas?
> 
> It looks to me like HAVE_PTRACE_GETXFPREGS is getting defined in config.h
> when it shouldn't be.

I don't think so.

# grep HAVE_PTRACE_GETXFPREGS config.h
/* #undef HAVE_PTRACE_GETXFPREGS */

> 
> The following comment may shed some light...
> 
> /* PTRACE_GETXFPREGS is a Cygnus invention, since we wrote our own
>    Linux kernel patch for SSE support.  That patch may or may not
>    actually make it into the official distribution.  If you find that
>    years have gone by since this code was added, and Linux isn't using
>    PTRACE_GETXFPREGS, that means that our patch didn't make it, and
>    you can delete this code.  */
> 
> Do you have PTRACE_GETXFPREGS defined in your system header files
> somewhere?
> 

No.

-- 
H.J. Lu (hjl@gnu.org)
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Updated MAINTAINERS file - work in progress
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A4FB7F.3B87A00F@cygnus.com>
References: <200002111033.LAA29442@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00241.html
Content-length: 423

Pierre Muller wrote:
> 
> At 21:33 10/02/00 -0800, you wrote:
> >> Andrew Cagney                        ac131313@cygnus.com?
> >> Stan Shebs                   shebs@cygnus.com?
> 
>   Wouldn't it be much more logical to have aliases here ?
> 
>   Andrew.Cagney@sourceware.cygnus.com
> or even better

We could.  Unfortunatly it would introduce a dependence on the fsf.org
admin and they already have enough to do.

	Andrew
From Stephane.Bihan@arccores.com Sat Apr 01 00:00:00 2000
From: Stephane.Bihan@arccores.com
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <OFFC5FBD39.F51E2E68-ON802568A3.00576DA1@risccores.com>
X-SW-Source: 2000-q1/msg00710.html
Content-length: 2269

>
> Stephane> I also use the breakpoint structure as an extern variable. I
> Stephane> needed it to implement the set_hw_breakpoint routine for the
> Stephane> remote protocol.  I think it's not the nicer way to do but
> Stephane> ....
>
> Can you explain?  I don't see any use of struct breakpoint in the
> current arc-tdep.c, nor do I see a set_hw_breakpoint function?

The version at FSF is a very old version out of date.
I am currently extending gdb for ARC to support user extensions.

>
> >> Since you say you can remove the single step code, I assume that the
> >> ISS target and remote protocol agents can perform the single step by
> >> themselves?  If so, it would be advantageous to disable GDB's single
> >> step support.  GDB would then issue a single "step" command instead of
> >> "insert breakpoint(s)", "continue", and "remove breakpoint(s)".  The
> >> latency of a step should be greatly improved.
>
> Stephane> I will implement this for the remote target only since the
> Stephane> hardware supports single-stepping.  I'm not sure if this
> Stephane> feasible in the ISS - Yuri?
>
> Stephane> If not feasible I won't disable the GDB's single step
> Stephane> support (thus enabling a call to single_step()) but I will
> Stephane> implement a single_step call to gdbstub in remote_resume().
>
> If your ISS target cannot support single step, but the remote protocol
> can, perhaps the best thing is to make software single step a target
> specific option.

By creating a target specific command?
The single step mechanism is a not a step-over-calls mechanism.

>
> I don't think that the arc is the only processor that would benefit
> from such a change.  For example, the sparclet ROM monitor supports a
> single step command, but I do not know if it is ever issued because
> the SPARC target uses software single step.  Perhaps it inserts the
> trap instructions needed for single step and issues the monitor step
> command?
>
> I do not think it's possible for any change to remote_resume() to be
> the right solution.
>
You're right, I've tried and if does not work.
Thanks for your explanations anyway.

Stephane.

----------------------------------------------------------------
Stephane Bihan
ARC Cores Ltd            http://www.arccores.com