headers
Mark Kettenis | 2 Aug 2006 00:38
Picon
Picon
Favicon

Bogus change to gdb.base/cursal.exp?

Nathan,

The gdb.base/cursal.exp test is currently failing for me:

Running ../../../../src/gdb/gdb/testsuite/gdb.base/cursal.exp ...
PASS: gdb.base/cursal.exp: set listsize 1
PASS: gdb.base/cursal.exp: list before run
ERROR: tcl error sourcing ../../../../src/gdb/gdb/testsuite/gdb.base/cursal.exp.
ERROR: wrong # args: should be "gdb_load arg"
    while executing
"gdb_load"
    (file "../../../../src/gdb/gdb/testsuite/gdb.base/cursal.exp" line 45)
    invoked from within
"source ../../../../src/gdb/gdb/testsuite/gdb.base/cursal.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source ../../../../src/gdb/gdb/testsuite/gdb.base/cursal.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name""
Running ../../../../src/gdb/gdb/testsuite/gdb.base/cvexpr.exp ...

Looking at these error messages, your last change to
gdb.base/cursal.exp:

2006-07-24  Nathan Sidwell  <nathan <at> codesourcery.com>

	* gdb.base/auxv.exp: Skip on non-linux, non-solaris targets.
	* gdb.base/cursal.exp: Use gdb_file_cmd first, then separate gdb_load.

just can't be right.  Can you please back the gdb.base/cursal.exp bit out?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 2 Aug 2006 00:58

Re: Bogus change to gdb.base/cursal.exp?

On Wed, Aug 02, 2006 at 12:38:18AM +0200, Mark Kettenis wrote:
> Looking at these error messages, your last change to
> gdb.base/cursal.exp:
> 
> 2006-07-24  Nathan Sidwell  <nathan <at> codesourcery.com>
> 
> 	* gdb.base/auxv.exp: Skip on non-linux, non-solaris targets.
> 	* gdb.base/cursal.exp: Use gdb_file_cmd first, then separate gdb_load.
> 
> just can't be right.  Can you please back the gdb.base/cursal.exp bit out?

I thought Nathan had fixed this on HEAD, but I guess he didn't check in
the fix.  I've taken care of this with the attached patch, from
gdb-csl-20060226-branch.

--

-- 
Daniel Jacobowitz
CodeSourcery

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/ChangeLog,v
retrieving revision 1.1244
diff -u -p -r1.1244 ChangeLog
--- ChangeLog	25 Jul 2006 04:24:50 -0000	1.1244
+++ ChangeLog	1 Aug 2006 22:57:07 -0000
 <at>  <at>  -1,3 +1,7  <at>  <at> 
+2006-08-01  Nathan Sidwell  <nathan <at> codesourcery.com>
+
+	* gdb.base/cursal.exp: Add "" to gdb_load call.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 2 Aug 2006 04:55

Is anyone using the HP compilers on PA-RISC with FSF GDB?

On Wed, Mar 01, 2006 at 11:12:00PM +0800, Randolph Chung wrote:
> Most of these have to do with how gdb handles c++ methods and member 
> variables, which makes me think that perhaps we should add some hooks to 
> the cp-abi layer to handle the type conversion logic. This takes care of 
> eval.c, valops.c, and maybe cp-valprint.c

> I notice that HP's wdb has better support for some of these cases. If we 
> were to clean up the above it will be worthwhile to look through wdb and 
> try to merge in some of the logic there (mostly to deal with member 
> functions)
> 
> Any thoughts? Is this even worth touching/fixing?

Some of it certainly is worth fixing.

I have a question, though, which I think I've asked before.  GCC on
HP/UX uses stabs, so only requires basic SOM support from GDB.  That
should be in decent shape still.  But the stuff read by hpread.c is
only generated by the HP compilers (cc and aCC).

- Are these compilers still important for C?
- Are these compilers still important for C++?

I have not heard from any users of the FSF GDB with the HP compilers in
a long time; for HP-specific features, I suspect more people use HP's
WDB fork of GDB.  If no one is using the HP support, I would like to
remove it from the next release of GDB.

The symbol reader (in hpread.c) is in dubious shape. It worked the last
time Michael Chastain ran it through testing - but that was a few
(Continue reading)

Permalink | Reply | 3 comments |
headers
'Daniel Jacobowitz' | 2 Aug 2006 05:03

Re: Interested in remote protocol improvements

On Sat, Jul 29, 2006 at 04:11:59PM +0200, Sascha wrote:
> I'll probably come up with some more problems when I work on the stub again.
> Something I'd be really interested in is the "step-range" packet you
> mentioned before. On a remote target stepping a C/C++ instruction can take
> some time as GDB fires a lot of step packets.

Yes, this is important.

> >Where does the GDB you're using come from?  I thought that I had fixed
> >CodeSourcery's to use the 'g' packet for any registers which are
> >available that way.  This isn't documented yet, but that version of GDB
> >will just decode bytes in the 'g' packet in the same order as the
> >"protocol numbers" from the target XML descriptions.  So one option is
> >to enlarge your 'g' packet.
> 
> It's the latest code sourcery arm-eabi-gdb.

I rewrote a bunch of the native Windows support code after our last release.
I bet that would help you with your networking performance problems. 
None of that code is on the branch; it's only available on the FSF
HEAD, which doesn't have the XML description stuff yet.

You probably can't use HEAD to debug your target, but do you want to
try building it and repeating the simple performance test?

> Maybe a small bug: The first time I replied to the 'g' packet with all
> standard arm registers (r.., f.., cpsr). But then GDB did NOT fetch the
> other registers using the 'p' packet. Instead it just reported the
> additional registers defined in target.xml as 0. Then I left out some
> registers (like cpsr) in the 'g' packet and it worked.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Nathan Sidwell | 2 Aug 2006 11:00

Re: Bogus change to gdb.base/cursal.exp?

Daniel Jacobowitz wrote:

> I thought Nathan had fixed this on HEAD, but I guess he didn't check in
> the fix.  I've taken care of this with the attached patch, from
> gdb-csl-20060226-branch.

thanks, it fell off my todo list.

nathan

--

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery
nathan <at> codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk
Permalink | Reply | 0 comments |
headers
Jim Blandy | 2 Aug 2006 20:13

Re: Testsuite regular expressions.


Daniel Jacobowitz <drow <at> false.org> writes:
> On Tue, Jul 25, 2006 at 01:09:02PM +0100, Andrew STUBBS wrote:
>> This is probably not a serious issue, but I do wonder if it perhaps 
>> would be better to sort it out.
>
> If you'd like to... I agree, but I don't think it's important enough to
> spend much time on.

One thing worth noting: backslash isn't special within {curly quotes}.

$ tclsh
% puts {foo\.bar}
foo\.bar
% puts "foo\.bar"
foo.bar
%

But I see that help.exp is using it in "double quotes", so yeah, it's
wrong.
Permalink | Reply | 0 comments |
headers
John David Anglin | 2 Aug 2006 21:16
Picon

Re: [Fwd: Is anyone using the HP compilers on PA-RISC with FSF GDB?] (fwd)

I've forwarded comments that I made in response to Daniel's message to
Randolph.

Forwarded message:
> From dave Wed Aug 2 11:45:40 EDT 2006
> Subject: Re: [Fwd: Is anyone using the HP compilers on PA-RISC with FSF GDB?]
> To: randolph <at> tausq.org (Randolph Chung)
> Date: Wed, 2 Aug 2006 11:45:40 -0400 (EDT)
> From: "John David Anglin" <dave <at> hiauly1>
> In-Reply-To: <44D019E7.2040405 <at> tausq.org> from "Randolph Chung" at Aug 2, 2006 11:20:07 am
> X-Mailer: ELM [version 2.4 PL25]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Content-Length: 2025      
> 
> > I have a question, though, which I think I've asked before.  GCC on
> > HP/UX uses stabs, so only requires basic SOM support from GDB.  That
> 
> There have been requests for ELF debug support.  The main issue as
> far as I can see is the lack of named sections and where to put stuff.
> 
> > should be in decent shape still.  But the stuff read by hpread.c is
> > only generated by the HP compilers (cc and aCC).
> > 
> > - Are these compilers still important for C?
> > - Are these compilers still important for C++?
> 
> Oh, I'm sure these compilers are still important to some people.
> However, I don't see the need to maintain support for the debug
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 2 Aug 2006 21:21

Re: [Fwd: Is anyone using the HP compilers on PA-RISC with FSF GDB?] (fwd)

On Wed, Aug 02, 2006 at 03:16:56PM -0400, John David Anglin wrote:
> > > I have a question, though, which I think I've asked before.  GCC on
> > > HP/UX uses stabs, so only requires basic SOM support from GDB.  That
> > 
> > There have been requests for ELF debug support.  The main issue as
> > far as I can see is the lack of named sections and where to put stuff.

Do you mean DWARF-2 here?  If so, I completely agree.  It seems like
SOM has some named sections - at least we're managing to get objdump to
tell me there's a GDB_STRINGS section - so I don't know what the
problem is.

> > > should be in decent shape still.  But the stuff read by hpread.c is
> > > only generated by the HP compilers (cc and aCC).
> > > 
> > > - Are these compilers still important for C?
> > > - Are these compilers still important for C++?
> > 
> > Oh, I'm sure these compilers are still important to some people.
> > However, I don't see the need to maintain support for the debug
> > format generated by these compilers.  There's no debug info in any
> > of the system libraries, so this capability doesn't help development
> > of open source applications under HP-UX.
> > 
> > I should also say that access to HP compilers is necessary to
> > maintain this code.  Thus, it really can only be done by HP.  If
> > they don't maintain it, then it should be removed.

At one point in the past, the Compaq testdrive systems offered aCC.  I
don't think they do any more though.
(Continue reading)

Permalink | Reply | 1 comment |
headers
John David Anglin | 2 Aug 2006 21:45
Picon

Re: [Fwd: Is anyone using the HP compilers on PA-RISC with FSF GDB?] (fwd)

> > > There have been requests for ELF debug support.  The main issue as
> > > far as I can see is the lack of named sections and where to put stuff.
> 
> Do you mean DWARF-2 here?  If so, I completely agree.  It seems like

Oops, yes DWARF-2.

> SOM has some named sections - at least we're managing to get objdump to
> tell me there's a GDB_STRINGS section - so I don't know what the
> problem is.

Yes, SOM has named spaces and subspaces.  However, we backed away from
using named sections in the SOM port a few years ago because there were 
issues with them in collect2's processing.  Section symbols and name
truncation, when using HP nm, caused problems with constructors/destructors.

There's no problem in generating named subspaces to hold the various
flavors of DWARF-2 debug info.  However, there is some dependence
on the presence of named section support in GCC's DWARF-2 output code
as I recall.  That's the only issue that needs a little thinking.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 0 comments |
headers
Mark Kettenis | 2 Aug 2006 23:17
Picon
Picon
Favicon

Re: Bogus change to gdb.base/cursal.exp?

> Date: Tue, 1 Aug 2006 18:58:22 -0400
> From: Daniel Jacobowitz <drow <at> false.org>
> 
> On Wed, Aug 02, 2006 at 12:38:18AM +0200, Mark Kettenis wrote:
> > Looking at these error messages, your last change to
> > gdb.base/cursal.exp:
> > 
> > 2006-07-24  Nathan Sidwell  <nathan <at> codesourcery.com>
> > 
> > 	* gdb.base/auxv.exp: Skip on non-linux, non-solaris targets.
> > 	* gdb.base/cursal.exp: Use gdb_file_cmd first, then separate gdb_load.
> > 
> > just can't be right.  Can you please back the gdb.base/cursal.exp bit out?
> 
> I thought Nathan had fixed this on HEAD, but I guess he didn't check in
> the fix.  I've taken care of this with the attached patch, from
> gdb-csl-20060226-branch.

> 2006-08-01  Nathan Sidwell  <nathan <at> codesourcery.com>
> 
> 	* gdb.base/cursal.exp: Add "" to gdb_load call.
> 

Sorry guys, but this still doesn't work on a native GDB:

Running ../../../../src/gdb/gdb/testsuite/gdb.base/cursal.exp ...
ERROR: couldn't load  into /home/kettenis/obj/gdb/gdb/testsuite/../../gdb/gdb (timed out).

So I repeat my request; would you be so kind to back this out until
you've found a solution that doesn't break this test on a native GDB?
(Continue reading)

Permalink | Reply | 2 comments |

Gmane