Re: Patches for GNU/Linux PPC native now in CVS

Re: Patches for GNU/Linux PPC native now in CVS

[Mark Kettenis]

   Date: Thu, 24 Feb 2000 03:25:41 -0700
   From: Kevin Buettner <kevinb@cygnus.com>

   On Feb 22, 11:13am, Mark Kettenis wrote:

   [Detailed failure analysis snipped]

   > Anyway, I hope this helps,

   It did indeed.  Thanks!  (It showed me where not to focus my attention
   first.)

   I'll respond to the sourceware list when I've had more time to study
   your analysis, but in the meantime, I wanted to send you a note to let
   you know that I appreciated your analysis...

Meanwhile, I learned something more about the

gdb.base/annota1.exp: backtrace @ signal handler

failure I reported.  There is nothing wrong with the test per se.
It's just that on my i586-pc-linux-gnu system the regexp matching
takes an awful lot of time.  Setting the timeout to 10 minutes made
the test pass.  This is probably related to the fact that with glibc
there is an extra frame.  Apparently the fix I suggested (but didn't
understand), speeded up the regexp matching somewhat, but even in that
case (with the default timeout) the test failed on my system last
night.

Sorry for the confusion.  I just couldn't imagine the regexp matching
taking the better part of 10 minutes :-(.

Mark
From khendricks@ivey.uwo.ca Thu Feb 24 05:56:00 2000
From: Kevin Hendricks <khendricks@ivey.uwo.ca>
To: Kevin Buettner <kevinb@cygnus.com>, khendricks@ivey.uwo.ca
Cc: gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Thu, 24 Feb 2000 05:56:00 -0000
Message-id: <00022408590700.29946@localhost.localdomain>
References: <1000222025201.ZM9805@ocotillo.lan> <00022221542500.09439@localhost.localdomain> <1000224101226.ZM14012@ocotillo.lan>
X-SW-Source: 2000-02/msg00005.html
Content-length: 1523

Hi Kevin B.

> > Everything was working fine until I decided to rerun the program
> > from within gdb without removing my shared library breakpoints
> > first.
> 
> Does it work if you disable your shared library breakpoints first?

I just tried it again (repeatedly) and I could not recreate the problem at all
either way (with or without disabling breakpoints first).  Now gdb just
politely disables the breakpoints it can't enable in shared libraries and I
just manually enable them later.

So I think this problem is caused either by stack/memory corruption or some
variable not being initialized properly.  It seems to be quite random.

I will keep playing with gdb and the jdk and let you know what is up.  If it
happens again, I will definitely try to get a pure c program that exhibits the
same problems.

> BTW, I just fixed one of the bugs (there were actually two separate bugs)
> which was causing one of the shared library tests to fail.  I'll commit
> this fix later on today, but I doubt it will solve your problem.

I will update my cvs tree tomorrow.

Again thanks for all your help.  I just need to play around with it some more
under native threads to make sure some of the old problems have not cropped
back up.

Overall a very big improvement!

Thanks,

Kevin

--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA   
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959

Re: Patches for GNU/Linux PPC native now in CVS

[Mark Kettenis]

   Date: Thu, 24 Feb 2000 03:25:41 -0700
   From: Kevin Buettner <kevinb@cygnus.com>

   On Feb 22, 11:13am, Mark Kettenis wrote:

   [Detailed failure analysis snipped]

   > Anyway, I hope this helps,

   It did indeed.  Thanks!  (It showed me where not to focus my attention
   first.)

   I'll respond to the sourceware list when I've had more time to study
   your analysis, but in the meantime, I wanted to send you a note to let
   you know that I appreciated your analysis...

Meanwhile, I learned something more about the

gdb.base/annota1.exp: backtrace @ signal handler

failure I reported.  There is nothing wrong with the test per se.
It's just that on my i586-pc-linux-gnu system the regexp matching
takes an awful lot of time.  Setting the timeout to 10 minutes made
the test pass.  This is probably related to the fact that with glibc
there is an extra frame.  Apparently the fix I suggested (but didn't
understand), speeded up the regexp matching somewhat, but even in that
case (with the default timeout) the test failed on my system last
night.

Sorry for the confusion.  I just couldn't imagine the regexp matching
taking the better part of 10 minutes :-(.

Mark
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Moving Linux-specific stuff out of i386-tdep.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000308175739.B12038@cygnus.com>
References: <200003082121.e28LLRu05681@delius.kettenis.local> <kettenis@wins.uva.nl> <1000308222742.ZM8876@ocotillo.lan> <20000308173031.A11900@cygnus.com> <cgf@cygnus.com> <1000308225132.ZM8953@ocotillo.lan>
X-SW-Source: 2000-q1/msg00625.html
Content-length: 562

On Wed, Mar 08, 2000 at 03:51:32PM -0700, Kevin Buettner wrote:
>...18-char names, so if you add a ~ for backups, ls can still list
>files in four columns.  Weak rationale perhaps, but there's no other
>technical limitations, and so the criterion can be usability.

Personally, I would chose clarity of the name over the fact that
ls output can fit in four columns.

But then, I think the gdb directory is in drastic need of a reorg,
too.  Maybe if we had something like a 'tdep' directory instead
of i386-linux-tdep.c we wouldn't have to worry about this.

cgf
From Franz.Sirl-kernel@lauterbach.com Sat Apr 01 00:00:00 2000
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: "Daniel Berlin" <dan@cgsoftware.com>
Cc: khendricks@admin.ivey.uwo.ca, gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <00020900262503.05214@enzo.bigblue.local>
X-SW-Source: 2000-q1/msg00178.html
Content-length: 2598

>>Simply put isn't it just *better* to get in something and let the users 
help to 
>>clean it up, make it work, improve it.  As a professor of TQM, waiting 
for 
>>perfection is just not the way to achieve it.  Getting everyone 
involved is.

>See, here is your fatal mistake.
>You are making the assumption that users will clean it up, make it work, 
>and improve it.
>While this may be true in other projects, it's not really true in GDB's 
>case.
>In fact, it's only true in GCC's case because there are more people who 
>understand the intricacies of compilers, and who are qualified to hack 
>on the compiler, than their are who understand the intricacies of joe 
>random platform's debugger interface.
>When it comes to things like drivers and debuggers, users don't really 
>help much, unless the architecture is so amazingly easy to understand 
>it's absurd. Which it isn't. Having ported sound drivers and whatnot to 
>BeOS, and talked with quite a few authors of sound drivers on linux, the 
>general consensus is that nobody submits patches. Their is the 
>occasional person who really enjoys hacking on undocumented hardware, or 
>poorly documented debugger interfaces, and who submits patches, but they 
>are very very rare.
>So what about the non-platform specific parts of GDB that are 
>understandable, and hackable?
>well, for the most part, they work great, and people are happy with 
>them, and thus don't submit patches.
>But just ot prove my point, when is the last time you saw a user submit 
>a patch for dwarf2 support, or C++ overload resolution (discounting me), 
>or support for a new platform?

Well, the point is that there is a patch out there by Kevin Buettner that once
was done in late 4.16 I think. It wasn't applied for 4.17 for legal reasons
which have since then be resolved (post the 4.18 release). But since then
nothing has been checked in into CVS (which could be somehow understandable),
but also no intermediate work has been posted on gdb-patches :-(. Se we know
there's something out there that is being worked on, but we cannot take part in
development, because there's nothing we can iterate on! We can only sit and
wait in this situation, or? And I think it's quite understandable that we get a
bit "nervous" when a new release is announced without support for Linux/PPC. In
fact, if Kevin Hendricks wouldn't have been faster than me, I would have started
this discussion :-)).

I think Kevin Buettner should checkin his current status into CVS, so that
there is at least _something_ we can report bugs against and maybe even do some
fixes.

Franz.
From fnasser@redhat.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: gdb@sourceware.cygnus.com, jtc@redback.com, Andrew Cagney <cagney@cygnus.com>, taruna@redhat.com, Eric Bachalo <ebachalo@cygnus.com>
Subject: Remote protocol extension for register ranges
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D8CFA4.C3535C93@redhat.com>
X-SW-Source: 2000-q1/msg00770.html
Content-length: 1276

Presently, the remote protocol can only read all registers of a target. 
This is OK for the context registers (the ones that are saved by the OD
on a context switch) but this is a serious limitation for machines that
have lots of additional registers.  It is just not feasible to read them
all at every "g" packet.

I would like to add parameters to the "g" packet.  Something similar has
been proposed before -- the only difference is that I would like the
parameters to be a register number or a register number range range.  

For instance: 

g82      Reads register 82
g31-40   Reads registers 31-40

Gdb would test for the acceptance of these types of packets by the stub
and fall back to the less efficient form if not (like it does for "P"
packets).

I really need this feature as do other people that are dealing with one
of the numerous microprocessors that have too many extra registers.  And
it is becoming quite urgent now.

What is the current thinking about this?  Are there other proposals I am
not aware of?  What are the maintainers position?

-- 
Fernando Nasser
Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory region attribute CLI
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003160944.EAA01842@indy.delorie.com>
References: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00718.html
Content-length: 424

> * create memory region:
> 
>         mem <start> <end> attribute [attribute ...]
> 
>   example:
>         (gdb) mem 0x00008000 0x0000FFFF ro 8
>         (gdb) mem 0x00007FF0 0x00007FFF rw
>         (gdb) mem 0x00007FE0 0x00007FEF wo 16
>         (gdb) mem 0x00007FD0 0x00007FDF ro

Could you please point to the discussions about this feature?  I find
it hard to understand what would be the usage of the memory regions.
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: muller@cerbere.u-strasbg.fr
Cc: gdb@sourceware.cygnus.com
Subject: Re: RFD: New command to inspect other selectors memory.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003031240.e23CeRn00162@delius.kettenis.local>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00519.html
Content-length: 1571

   Date: Fri, 03 Mar 2000 09:27:14 +0100
   From: Pierre Muller <muller@cerbere.u-strasbg.fr>

   I inserted this in a reply about pascal extension, but as I got no answer,
   I thought
   I will send it as a separate message.

Sorry about that.

   I have written for DJGPP target a relatively small patch.
   It allows to read memory from another selector
   this was very useful for me when I tried to debug the debugger itself and 
   when I added exception support fro GDB on DJGPP !

   This patch consists of the addition of one command that I called "xx"
   which is a simple clone of the "x" command but can take a selector 
   as for intance 
      "xx $fs:0x400"
   then the next "xx 0x800" keeps using the last selector value.
   I do not know if this could be interesting for other i386 targets
   (maybe for win32 to be able to see the content of the $fs selector
   that contains the exception chain, but I am not sure how if its
   readable inside a win32 API program).

     Is such kind of patch too specific to have any chance to get accepted ?
   I don't know if it could be of any use for other processors or operating
   system !!

This may be impossible to implement on most i386 targets (with the
possible exception of Solaris and Mach-based targets), but nevrtheless
it could be useful to have for things that are a bit more low-level
(like debugging a threads library that uses segmentation to store
per-thread data and such).  The suggested syntax could probably be
improved, since "xx" isn't very descriptive.  People with bright ideas?

Mark
From jsm@cygnus.com Sat Apr 01 00:00:00 2000
From: Jason Molenda <jsm@cygnus.com>
To: gdb@sourceware.cygnus.com, gdb-testers@sourceware.cygnus.com
Subject: New GDB CVS repository is set up!
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000206224315.A25084@cygnus.com>
X-SW-Source: 2000-q1/msg00119.html
Content-length: 3832

Hi folks!  

The new GDB repository is set up.  If you have a checked out copy of the
GDB repository, you're going to check out a brand new one.  Read this
whole message.


This weekend I merged the GDB repository with the binutils repository
which was already on Sourceware.  For those of you working on both gdb
and binutils, the merging of these two will ease your life considerably.

I treated the binutils repository as the master repository, so whenever
there was overlap between the gdb repository and the binutils repository,
the files from the binutils repository were used.  Binutils and GDB
have not been synchronized/merged in approx six months, so we're going
to have some instability this week.  Cygwin support in binutils is just
plain broken right now. :-/

The following directories from the GDB repository were incorporated in
to the new repository with no changes:  

   dejagnu, expect, gdb, mmalloc, readline, sim, tcl, utils

The following directories from the binutils repository were incorporated
in to the new repository with no changes:

   bfd, config, etc, gas, gprof, include, intl, ld, libiberty, opcodes, texinfo

And all of the top-level files were from binutils as well.

If you have changes in your checked-out tree, and the changes are all
in the directories that came from GDB, you are fine -- do a cvs diff
of your existing tree, check out a new tree and apply the patches.
They'll apply cleanly.

If you have changes in your checked-out tree in the directories from
the binutils repository, you should still do the diff in the old GDB
repository so you have a clear idea of what you changed, but the changes
may not apply cleanly to the binutils version of that directory.  You may
need to do some work to get it applied cleanly.



Most people will have few, or no, changes to their checked out copy of the
GDB repository.  Those people should just remove their checked out copy
and get a new one.  Andrew Cagney suggested that a lot of people will do
this, so I've tarred up pre-checked-out trees using the anoncvs pserver
method -- just download one of these tarfiles and you'll be good to go.

In ftp://sourceware.cygnus.com/pub/gdb/snapshots/ you'll find:

       9102999 Feb  6 19:38 gdb-pserver-2000-02-06.tar.bz2
       2230176 Feb  6 19:42 dejagnu-pserver-2000-02-06.tar.bz2
      11027699 Feb  6 20:01 gdb-dejagnu-pserver-2000-02-06.tar.bz2
      14246962 Feb  6 20:20 insight-pserver-2000-02-06.tar.bz2

The "gdb-pserver-2000-02-06.tar.bz2" is just GDB.

The "dejagnu-pserver-2000-02-06.tar.bz2" is just dejagnu.

The "gdb-dejagnu-pserver-2000-02-06.tar.bz2" is GDB and dejagnu.

The "insight-pserver-2000-02-06.tar.bz2" is Insight.

If you want to check out a tree for yourself, the instructions on
the GDB web page ( http://sourceware.cygnus.com/gdb/ ) are updated.
In short, you want to do

 cvs -z9 -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src login
   ("anoncvs" for the password)
 cvs -z9 -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co gdb


As I wrote previously, changes to the GDB repository will now happen
almost entirely in this public repository.  If you want to see cvs
commit messages as they happen, sign up to the gdb-cvs mailing list
(there are instructions on the GDB home page for getting on this) or
monitor its web archive.


Much credit for this repository move goes to Andrew Cagney who has been
moving (literally) mountains of code in the face of lame Australian
infrastructure :-) and an already heavy work load.  This move would have
been a disaster without the overdue reorganizations and cleanups he did
last week.  Thanks Andrew!


This is a significant change, and I expect some people to have problems.
I doubt I've thought of every possible confusion or complication in
this move.  Ask me if you have any questions.


Jason
Free the Software!
From toddpw@windriver.com Sat Apr 01 00:00:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: jsm@cygnus.com (Jason Molenda)
Cc: gdb@sourceware.cygnus.com (GDB Developers)
Subject: Re: GDB ftp site in hyperspace ...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002010659.WAA04719@alabama.wrs.com>
References: <20000131225201.A11482@cygnus.com>
X-SW-Source: 2000-q1/msg00083.html
Content-length: 604

> (I'm not joking about the Solaris ftp client being broken; I think it
> will still work if there is at least one file in a given directory.  The
> directory you're looking at has no files in it, only subdirectories)

Think you could stick a content-free README in there then??

I can't imagine you enjoy the prospect of having to answer this question
more than a few times, unless you simply enjoy bagging on Solaris. (This
I can understand, but still...)

FWIW I run NetBSD at home; at work my options right now are Solaris and NT
-- obvious choice there ...

-- 
Todd Whitesel
toddpw @ windriver.com
From khendricks@ivey.uwo.ca Sat Apr 01 00:00:00 2000
From: Kevin Hendricks <khendricks@ivey.uwo.ca>
To: dan@cgsoftware.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <00020823060800.00592@localhost.localdomain>
References: <950048577_PM_BeOS.dan@cgsoftware.com>
X-SW-Source: 2000-q1/msg00183.html
Content-length: 2478

Hi,

> What you are really saying is that it's better to put hacks and crap in 
> the tree, and hope someone comes along and does it right, removing the 
> hack, while making it even more a living hell for everyone else to 
> understand.

Why is eveything "not perfect" considered a hack or crap?  I for one don't
think Kevin Buettner's patch is a hack or crap at all. Please stop equating
what we want to see added with crap.

> See, here is your fatal mistake.
> You are making the assumption that users will clean it up, make it work, 
> and improve it.
> While this may be true in other projects, it's not really true in GDB's 
> case.

I think your attitude here is just wrong (and frankly part of the whole gdb
problem).  You obviously think you have cornered the market on some unique
programming skill.  This is simply not true.  Users can and will help.  I would
help (I was part of Blackdown's jdk porting team until recent events forced me
to move on), Franz would help (he is *the* gcc person for ppc and without his
work with them we (ppc) would still be in the dark ages, Gary Thomas would help
(he is really the father of the whole linux ppc movement and is single handedly
responsible for much of the code that ppc uses), etc.  We just need something
to start playing with.  As it stands, we can't even submit official bug
reports.   

Please stop thinking that gdb is so complex that only a maintainer can help
(seen the inside of many multi-threaded virtual machines latesly?).  Sure we
won't be as good as you, we won't be as productive as you, but we (and others)
really can help. I think we are proof of that.  Unfortunately when I submitted 
the original ppc patch (based on Kevin Buettner work) back around 4.16 or
earlier,  I just never dreamed it would take this long to get anything there
done with it.  

Perhaps cygnus plays too large a role in tool development.  Perhaps open source
tools should not be tied so closely to any one company.  Too many conflicts of
interest?  Too many paying customers versus the rest of us?  I just don't know.

But whatever the outcome, please stop assuming that all "users" are idiots. 
This is simply not the case and results in much of the bad or negative
"mindset" I have seen in the gdb lists and tried to point out to Stan.

Thanks for responding to my post.  I am not sure we will ever agree on how
things should be done but we are talking about it which is more than has been
done of late.

Take care,

Kevin
From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: kettenis@wins.uva.nl (Mark Kettenis)
Cc: gdb@sourceware.cygnus.com
Subject: Re: Testsuite regression
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003261941.VAA32661@reisser.regent.e-technik.tu-muenchen.de>
References: <200003261706.e2QH6Yn08493@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00812.html
Content-length: 2275

I noticed this to, it is caused by:

2000-03-14  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>

        * gdb.base/printcmds.c: Add typedeffed arrays.

which now puts a nonzero word after ctable2 in gdb.base/printcmds.c via
ArrayInt a1 = {2,4,6,8,10,12,14,16,18,20};

Previous versions had
int int1dim[12] = {0,1,2,3,4,5,6,7,8,9,10,11};
after ctable2, putting a zero word there.

So we now have a non zero byte after ctable2 (but only on little endian
targets).

p &ctable2[15*16]
asks GDB to print an unsigned char pointer and GDB puts out the contents
of the pointer as a string as well. As the string is no longer zero
terminated, GDB appends ellipsis.

It could be fixed by appending a zero byte to ctable2 (but I have tested
this only lightly):

*** gdb/testsuite/gdb.base/printcmds.c.orig	Wed Mar 22 19:08:22 2000
--- gdb/testsuite/gdb.base/printcmds.c	Sun Mar 26 21:34:20 2000
***************
*** 53,59 ****
    'a','a','a','a','a','a','a','a','a','a','a','a','a','X','X','X',
    'a','a','a','a','a','a','a','a','a','a','a','a','a','a','X','X',
    'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','X',
!   'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','a'
  };
  
  /* Single and multidimensional arrays to test access and printing of array
--- 53,59 ----
    'a','a','a','a','a','a','a','a','a','a','a','a','a','X','X','X',
    'a','a','a','a','a','a','a','a','a','a','a','a','a','a','X','X',
    'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','X',
!   'a','a','a','a','a','a','a','a','a','a','a','a','a','a','a','a', 0
  };
  
  /* Single and multidimensional arrays to test access and printing of array

> Hi all,
> 
> Somewhere between March 9 and March 15, the following failure appears:
> 
>   FAIL: gdb.base/printcmds.exp: p &ctable2[15*16] with print elements set to 16
> 
> This is the output from a run where the test still passed:
> 
>   p &ctable2[15*16]
>   $538 = (unsigned char *) 'a' <repeats 16 times>
> 
> And this the current output:
> 
>   p &ctable2[15*16]
>   $538 = (unsigned char *) 'a' <repeats 16 times>...
> 
> I'm a bit puzzled though what change is responsible for this
> regression.  Is there anybody else observing this failure?
> 
> Mark

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: blizzard@redhat.com
Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com
Subject: Re: problems with gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002182124.QAA13729@devserv.devel.redhat.com>
References: <38A47E89.3F4674B3@mozilla.org> <npael3tqk6.fsf@zwingli.cygnus.com> <38AB2DC4.FA9A3C71@redhat.com> <87zot0y99f.fsf@cygnus.com> <38AC0B97.19AE4BAE@mozilla.org> <38AD8469.27616453@redhat.com> <200002181916.e1IJGuA00449@delius.kettenis.local> <38ADA340.DF649E22@redhat.com> <200002182034.e1IKYlf00214@delius.kettenis.local> <38ADB0B9.4D4D6F10@redhat.com>
X-SW-Source: 2000-q1/msg00346.html
Content-length: 886

> I think that the version that I have is based on a snapshot from 19991004. 
> Jim should know more.  Jim?

You are working off the gdb-4.18-10.src.rpm which is in Red Hat Linux
6.2beta?  While I am interested in knowing whether that version is
totally broken for multi-threads (when combined with glibc and
everything else from 6.2beta), I've given up on making it usable for
Mozilla (given that 6.2beta is already frozen and the number of
mozilla developers is small compared with the total number of people
using Linux).  I just don't see how to do it without too much risk of
breaking something else.

The key task is in getting GDB in CVS fixed.  You just told me to get
Mozilla from CVS (it is building now, I know because the fan on my
laptop is in high speed mode and will be for the next hour or so :-))
so turnabout is fair play and I can tell you to do the same for GDB
:-)
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Grant Edwards <grante@visi.com>
Cc: Daniel Berlin <dan@cgsoftware.com>, gdb@sourceware.cygnus.com
Subject: Re: Dwarf Error: Could not find abbrev number 1.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <em9h9m9j.fsf@dan.resnet.rochester.edu>
References: <20000311140313.A32545@visi.com> <Pine.LNX.4.10.10003111303170.4419-100000@propylaea.anduin.com> <20000311152157.A640@visi.com>
X-SW-Source: 2000-q1/msg00679.html
Content-length: 740

Grant Edwards <grante@visi.com> writes:

How old is the old binutils?
There seem to be some LMA related changes to ld from 02-16-99, that
would have affected arm-elf.

--Dan
> On Sat, Mar 11, 2000 at 01:06:17PM -0800, Daniel Berlin wrote:
> 
> > You have both stabs and dwarf debug info in the same executable?
> 
> I guess so.  I have whatever arm-elf-gcc -g generates.
> 
> > (It's rhetorical, the .stab section confirms it) This is most
> > likely the problem.
> 
> It turns out that removing the .stab sections makes no difference.
> 
> What fixes things is forcing the VMA/LMA of all of the .debug_*
> sections to 0. (Regardless of the presence of the .stab
> sections).  Perhaps this was the default behavior of the older
> binutils?
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: shebs@apple.com, "K. Richard Pixley" <rich@microunity.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: test suites?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D5BA28.94F9A2EC@cygnus.com>
References: <200003162238.OAA19924@wicket.microunity.com> <38D2955A.8236559A@apple.com>
X-SW-Source: 2000-q1/msg00742.html
Content-length: 930

Stan Shebs wrote:
> 
> "K. Richard Pixley" wrote:
> >
> > What are people using for regression testing on gdb these days?
> 
> The same old testsuites that we were using when you were at Cygnus!
> 
> OK, there have been some additions and restructuring, but the
> theory is unchanged; they all live under src/gdb/testsuite,
> you get a recent dejagnu and install, then do "make check" in
> your objdir.

To expand a little.

Dejagnu is included in the nightly shots (gdb+dejagnu.tar.gz,...) or as
a separate file. Alternativly, you can check it out, along with GDB,
vis:

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

This ensures that the dejagnu you test GDB with is the same one that
everyone else is using.

	Andrew

PS: which reminds me, now that nightly snapshots are working (....) I
need to start a discussion on what the snapshots should contain.
ftp://sourceware.cygnus.com/pub/gdb/snapshots/
From pici@flatline.koli.uni-miskolc.hu Sat Apr 01 00:00:00 2000
From: Jonyer Otto <pici@flatline.koli.uni-miskolc.hu>
To: gdb@sourceware.cygnus.com
Subject: Re: symbol table architecture problems
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.21.0001060008180.7225-100000@flatline.koli.uni-miskolc.hu>
References: <Pine.LNX.4.21.0001052045050.1731-100000@flatline.koli.uni-miskolc.hu>
X-SW-Source: 2000-q1/msg00009.html
Content-length: 259

Helo!

Now I can see, that gdb has hash.c and good functions in it but it does not
seem using it so efficient because of the too much strcmp()s.
If someone knows how could I increase the efficacy somehow.

(I countinue looking at the sources and docs)

Pici

Re: Patches for GNU/Linux PPC native now in CVS

[Kevin Hendricks]

Hi Kevin B.

> > Everything was working fine until I decided to rerun the program
> > from within gdb without removing my shared library breakpoints
> > first.
> 
> Does it work if you disable your shared library breakpoints first?

I just tried it again (repeatedly) and I could not recreate the problem at all
either way (with or without disabling breakpoints first).  Now gdb just
politely disables the breakpoints it can't enable in shared libraries and I
just manually enable them later.

So I think this problem is caused either by stack/memory corruption or some
variable not being initialized properly.  It seems to be quite random.

I will keep playing with gdb and the jdk and let you know what is up.  If it
happens again, I will definitely try to get a pure c program that exhibits the
same problems.

> BTW, I just fixed one of the bugs (there were actually two separate bugs)
> which was causing one of the shared library tests to fail.  I'll commit
> this fix later on today, but I doubt it will solve your problem.

I will update my cvs tree tomorrow.

Again thanks for all your help.  I just need to play around with it some more
under native threads to make sure some of the old problems have not cropped
back up.

Overall a very big improvement!

Thanks,

Kevin

--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA   
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959

Re: Patches for GNU/Linux PPC native now in CVS

[Franz Sirl]

At 10:52 24.02.00 , Kevin Buettner wrote:
> > 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.

Ok, I just wanted to clear the status of "info float", I'll take a look at 
it too and maybe I should already think about "info vector" :-)).

Franz.

Re: Patches for GNU/Linux PPC native now in CVS

[Kevin_Hendricks]

Hi Kevin B.,

>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 just finished grabbing the source from anonymous cvs from sourceware onto my 
work machine and I will take it home and build it tonight and give it try at 
debugging the native threads jdk and let you know if I run into any problems.

Thanks for all your hard work!

Take care,

Kevin

(ps. in all of your spare time....you could be a big help at Blackdown, we are 
beginning the port to jdk 1.3 and the HotSpot...care to rejoin the ppc JDK 
effort?!).

Thanks again.

Kevin H.

--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA   
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959