Re: problems with gdb

Re: problems with gdb

[Chris Blizzard]

Jim Kingdon wrote:
> 
> > 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
> :-)

Yeah, I'm trying the latest snapshot ( marked today. :D )  Doesn't build but
the problems look pretty easy to fix.

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
I think the mistake a lot of us make is thinking the state-appointed
psychiatrist is our "friend."
------------
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: shebs@shebs.cnchost.com
Cc: Jason Molenda <jsm@cygnus.com>, gdb-testers@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: GDB snapshot 2000-01-31 out and IMPORTANT ANNOUNCEMENT
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <3897872C.BA5EF657@cygnus.com>
References: <20000131214333.A11195@cygnus.com> <389710D7.6EF7B5A8@shebs.cnchost.com>
X-SW-Source: 2000-q1/msg00091.html
Content-length: 914

Stan Shebs wrote:
> 
> Jason Molenda wrote:
> 
> > Here is the real crowd pleaser:  At the end of the week I am going
> > to migrate the active GDB repository from our internal repository
> > to sourceware.cygnus.com.  This means that all non-confidential[1]
> > GDB development done here at Cygnus will be done in full public view.
> > You'll be seeing the changes as they are added, warts and all. :-)
> 
> This is great, at long last!  Is this going to be separate from the
> binutils on sourceware still, or are you going to merge repositories?

No. Yes. :-)

Jason, who is co-ordinating things with the binutils group, is going to
combine the two repositories.  As I mentioned in a separate posting
there is going to be some fallout and it will take a little time for
things to settle down again.  At present GDB's bfd is very out-of-date.

There are no immediate plans to also combine GCC.

	enjoy,
		Andrew
From tromey@cygnus.com Sat Apr 01 00:00:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Try out the patch database
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <877lfmbkah.fsf@cygnus.com>
References: <200002292134.QAA10095@zwingli.cygnus.com> <1000229221310.ZM16579@ocotillo.lan> <npem9ulja1.fsf@zwingli.cygnus.com> <38BD61EF.81A4E3C6@marconicomms.com>
X-SW-Source: 2000-q1/msg00477.html
Content-length: 548

>>>>> "Guenther" == Guenther Grau <Guenther.Grau@marconicomms.com> writes:

Guenther> Third, (but not very important) why do you use persistant
Guenther> cookies? I don't like cookies und usually disable them,
Guenther> but I could live with session cookies, if you really insist
Guenther> on them. But persistent cookies that last for a month are
Guenther> not what I like.

This is a decision made by the gnatsweb authors.  I don't know why
they did it, and I don't really like it either, but you'd have to take
it up with them.

Tom
From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Pascal language support patch preparation
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003021452.PAA02334@cerbere.u-strasbg.fr>
References: <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00503.html
Content-length: 817

>>The best thing would probably be to port these changes over to the
>>p-*.* files.
>
>   Of courseit would, but I would like to stress again that I am a 
>pascal programmer (a bit assembler also) but that I learned C only to be
>able to
>add pascal to GDB!!!
>  
>  So I am probably not the best person to do this without errors :(

   I just tried to get the diffs to see how difficult this would be:

  the diffs are mainly due to the reformating thus it is very difficult to
find out where 
the code really did change!!

  The logs are also useless as most only are weekly imports from the
workers CVS 
before the CVS was made public!



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: patl@cag.lcs.mit.edu
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: <200002081550.QAA19536@landau.wins.uva.nl>
References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> <bog9tj5y3.fsf@rtl.cygnus.com> <20000207093417.A10546@lucon.org> <200002071746.MAA22221@devserv.devel.redhat.com> <20000207095901.A10677@lucon.org> <389F6FD1.7BA7FC12@cygnus.com> <s5gitzz68wv.fsf@natasha.curl.com>
X-SW-Source: 2000-q1/msg00167.html
Content-length: 2810

   From: patl@cag.lcs.mit.edu (Patrick J. LoPresti)
   Date: 08 Feb 2000 09:55:28 -0500

   Andrew Cagney <ac131313@cygnus.com> writes:

   > With that said, I would consider a one month gap between 5.0 and 5.1 to
   > be unrealistic. I'd also consider it un-reasonable to mandate the
   > acceptance of patches just because a reasonable solution isn't
   > available.

   I think it depends on the situation.  At this point, stock GDB has
   been broken on Linux/x86 for several *years*.

Depends on what you call broken I guess.  Stock GDB 4.17 was pretty usable.

   The problem with debugging across dlopen()/dlclose()/dlopen() sounds
   complicated.  It is also fairly obscure.  However, being unable to use
   breakpoints in *any shared library at all* is not obscure.  It makes
   stock GDB extremely painful for a lot of uses.  If GDB 5.0 is released
   with the same problem, I suspect the word among Linux developers will
   be the same as it has been for the last few years: "Stock GDB is
   broken; don't use it."

I just noticed that the FreeBSD folks seem to have a solution for the
dlopen()/dlclose()/dlopen().  It isn't that obscure.  It simply isn't
implemented.  That might take a few hours for a competent GDB hacker, and
a few more for somebody who doesn't know GDB too well.  But the
FreeBSD code looks reasonable at first sight, so I think I can fix
things eventually.  Just not overnight.

Why do people think that breakpoints in shared libraries don't work at
all?  They didn't work in GDB 4.18, because of a bug-fix for SunOS 4
that broke most of the other systems.  That was corrected shortly
after the release, and if you use a recent GDB snapshot everything
seems to work fine.

If you can privide a test-case where setting breakpoints in a shared
library breaks things in a recent GDB snapshot, please do so.  AFAIK
none of the people who're actively hacking on the GDB code is aware of
such a problem.

   The SamL/H.J. patches fix the problem, as far as we can tell here.
   And those patches are not very large.  Is it really so hard to put
   them in and fix the problem the Right Way later?  The argument "we
   can't accept every hack" is pretty weak.  You are not being asked to
   accept every hack, you are being asked to accept a single hack which
   addresses a very serious problem on a major platform.

Well, the hack is pretty gross, AFAICT only relevant for the multiple
dlopen()/dlclose() scenario, and needs some work anyway.  Sam provided
HJ with two patches that seem to address the same problem, and the
code that HJ sent yesterday looks completely bogus to me!  The patch
affects all platforms using SunOS-style shared libraries or ELF shared
libraries.  And, can we please first establish what the exact bug is before
we start trying to hack around it!

Mark
From fnasser@redhat.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: Grant Edwards <grante@visi.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B2AD14.7B0B4A4E@redhat.com>
References: <20000221104541.A28578@visi.com>
X-SW-Source: 2000-q1/msg00369.html
Content-length: 1275

Grant Edwards wrote:
> 
> The RDI target support seems to be broken in the 000215
> snapshot.  I'm unable to execute any of the eCos test programs,
> or any other applictions I've written. (they run fine with a
> patched-up 4.18 gdb).  I don't know what's wrong with it and
> won't have time to look at it for a while.
> 
Can you be more specific?  It is working right with the AEB board and
with another one I have here.  Both use serial ports.

I am not using that specific snapshot and I have no idea what sort of
problems you may be encountering.  There was sort of a code freeze so it
should not be much different from others.

Please let me know what is your host machine, what version of tools did
you use to build gdb, if on cygwin, which version of the dll and, last
but not least, what is it that you are getting on the console.


> Is somebody currently working on the RDI code?  If so, I'll
> leave well enough alone until the code stabilizes.
> 
The usual folks.  You, myself, Thomas, Nick, Jim...  and I build and
test it at least twice a week.

-- 
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 tromey@cygnus.com Sat Apr 01 00:00:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: breakpoint hit counts
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <87ln5w6sh1.fsf@cygnus.com>
X-SW-Source: 2000-q1/msg00022.html
Content-length: 603

I recently was debugging with gdb and I typed "c 57" instead of "b 57"
(a simple typo).

I was suprised to learn that gdb preserves the ignore count even when
I re-ran my program.  I would rather have gdb reset the ignore count
when I re-run.

As it turns out, the actual rule is that ignore counts are reset
unless hit count display is enabled (the default).

To me this rule seems obscure, and the feature seems fairly useless.
I'd like to change gdb to always clear the ignore count when the
inferior is re-run.

Any comments on this?  Does anybody rely on the current scheme?  If
so, what for?

Tom
From jimb@cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Try out the patch database
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <npem9ulja1.fsf@zwingli.cygnus.com>
References: <200002292134.QAA10095@zwingli.cygnus.com> <1000229221310.ZM16579@ocotillo.lan>
X-SW-Source: 2000-q1/msg00472.html
Content-length: 746

> > Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and
> > let me know what you think.
> 
> I see two patches in the gdb database.  (There was only one a little
> while ago.)  I'd like to see how the attachment mechanism works.  I
> downloaded the Kublai Khan poem, but it's in html.  I'd like to see
> a real patch that I can download.
> 
> Also, I think it'd be useful to be able to view a patch in the web
> browser as well as download it to a file.  It's not clear to me that
> both of these capabilities are available.

This is an area of concern for me, too.  If you look at gdb-patch/7,
there's some weirdness going on with the indentation that I'm not
happy with.

I think the gnatsweb script may require some hacking.
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: hjl@valinux.com
Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A revised patch for dlclose
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003080058.e280wga00453@delius.kettenis.local>
References: <20000307120800.A27315@valinux.com>
X-SW-Source: 2000-q1/msg00578.html
Content-length: 918

   Date: Tue, 7 Mar 2000 12:08:00 -0800
   From: "H . J . Lu" <hjl@valinux.com>

   Here is a revised patch for dlclose. If you take a look at the
   dynamic linker in glibc 2.1 or above, you will find that it informs
   gdb about loading/unloading a shared library via an internal debug
   function, _dl_debug_state (). gdb already handles the loading in
   handle_inferior_event () with BPSTAT_WHAT_CHECK_SHLIBS and
   BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK. However, we need also
   check the unloading event. solib_verify () will be called only when the
   dynamic linker calls _dl_debug_state (). It shouldn't introduce any
   overhead. I believe it is on the right track although it may be further
   optimized.

HJ, please stop wasting your time pushing this patch.  The patch has
several bad points, that you cannot fix without considerable changes
to the way solib.c handles and caches the link map.

Mark
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: mark@codesourcery.com (Mark Mitchell)
Cc: kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com
Subject: Re: Regressions problem (200 failures)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003021143.MAA14294@reisser.regent.e-technik.tu-muenchen.de>
References: <20000302023420H.mitchell@codesourcery.com>
X-SW-Source: 2000-q1/msg00494.html
Content-length: 935

>     Peter> For practical debugging purposes (especially C++), the line
>     Peter> number information (and thus the breakpoint) has to be put
>     Peter> before the initialization code for local variables, so that
>     Peter> we can debug object initialization.
> 
> But the line number itself doesn't have to indicate the `{'; it could
> indicate the next line, if that's what GDB wants.  This is more
> possible than it used to be since the C++ front-end now puts out whole
> functions at once, rather than processing a statement at a time.
> 
> Still, it's non-trivial.

From a pure user perspective (for now not considering implementation problems 
with GCC or GDB), a breakpoint on the opening brace is not what I want,
as I will almost always have to step over it.
I'd expect a breakpoint on the first local variable that needs initalization,
or the first statement.

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From gatliff@haulpak.com Sat Apr 01 00:00:00 2000
From: William Gatliff <gatliff@haulpak.com>
To: gdb@sourceware.cygnus.com, crossgcc@sourceware.cygnus.com
Subject: Re: gdbstubs library posted at sourceforge
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <3891C982.32326D7E@haulpak.com>
References: <200001271910.OAA04242@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00069.html
Content-length: 4682

Jim:

Jim Kingdon wrote:

> > I just moved my gdbstubs library to sourceforge.net.
>
> Cool!  I've added a link from http://sourceware.cygnus.com/gdb/ - at the
> bottom of the page with the other links.

Thanks!


> > The release license is LGPL.
>
> Are you sure you want this rather than public domain (as the stubs in the
> GDB distribution) or XFree86-style?  I suppose maybe it is a moot point
> if people leave out the stubs when they actually ship code, but in
> general, the LGPL's requirement that people make available .o's makes it
> somewhat impractical for many embedded applications.

Actually, that's a good question.  The following are my concerns, which I
think the LGPL addresses, although not perfectly.  I'm open to differing
opinions and suggestions, though, as I'm no expert:


   * I want to encourage leaving the stubs in production embedded systems
   * I don't want to force users to divulge the non-gdbstubs parts of their
     application if they don't want to
   * I want to avoid proprietary, closed-source modifications to the stubs;
     minor tweaks to overcome hardware and security issues are fine, but
     nothing that makes it work better with gdb than the public sources
   * I want to encourage contributions to the stubs
   * I don't want someone turning gdbstubs itself into a closed source
     product (particularly the tracepoint stuff, when it arrives)

Straightaway, the first, second and last points seem to rule out GPL.

My problem with the public domain distribution of the gdb-distributed stubs
is that they don't encourage the kind of thing I'm doing--- cooperative
building of more advanced stubs, to try and make gdb an increasingly
attractive debugger for embedded systems.  The MIT license seems to have a
similar problem, in that it allows users to modify gdbstubs without
returning those modifications to the community.

As I understand it, linking an LGPL work with a proprietary application
doesn't force one to divulge the source for the application, but they must
divulge modifications to the LGPL'd work, so I'm pretty good so far.  The
.o requirement would come up if someone wanted to update the stubs without
updating the application, but that doesn't seem like a circumstance that's
likely to come up, at least not on the kinds of embedded systems I'm
familiar with. [note: this is an open invitation for experiences to the
contrary!]  So, it still seems ok, at least in my current world.

Maybe CEPL is a closer fit for what I'm after, because it accomplishes
everything the LGPL does *and* eliminates the need for .o's?  I could go
there.

I suppose that I can also offer alternate licenses for people who want to
make proprietary modifications, but I'm hesitant to do so because:

   * it's a headache, and I don't want to pay that much attention to the
     process
   * I don't want to get into disputes over ideologies with contributors
   * I'm having trouble seeing what a "proprietary" extension might
     actually be
   * I don't want "forks" of proprietary extensions with nifty features not
     found in the public code base
   * it's just not good karma  :^)

Several other people have expressed concerns with the LGPL to me
privately.  I would appreciate said people (you know who you are!) making
the background for their objections known publicly, so that we can arrive
at a workable solution.  I'll follow consensus as long as it's the most
realistic solution available for the motivations I list above.

Myself, I don't think I have a problem with LGPL because I don't intend to
make proprietary mods to gdbstubs, and I don't expect my clients (who get
source anyway) or customers (who wouldn't know what to do with it) to want
to update their stubs.  My products don't ship with stabs information
either, so the stub is of little value except for engineering-level
testing.  I admit that my avoiding the possiblity of a .o distribution
doesn't really eliminate it, however...

I am PERFECTLY HAPPY to select a different license, as long as it's one
that doesn't permit proprietary mods to gdbstubs itself.

Ideas?


> > I'll also take any suggestions on how to manage the project--- I'm not
> > exactly skilled in the art of extreme multitarget development, at
> > least not yet.  :^)
>
> You've already done the hard part by being dumb ^H^H^H^H brave enough to
> start the project!  Feel free to ask if you have specific questions.

LOL.  :^)

How about pointers to a tutorial on configure?  Seems like it would be nice
to be able to do 'configure --target=x-y-z', but maybe that's overkill.

b.g.

--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems
To teach is to learn.

Re: problems with gdb

[Chris Blizzard]

Christopher Blizzard wrote:
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x404cbd41 in ?? () from /lib/libc.so.6
> (gdb) shar libc.so.6
> Reading symbols from /lib/libc.so.6...done.
> 

So, I've done some more digging into this and it looks like Jim Kingdon has
reported this problem in the past:

http://sourceware.cygnus.com/ml/bug-gdb/1999-10/msg00058.html

I can reproduce this problem both with and without Tom's patch.  Has anyone
seen this before?  Maybe have a solution for it hanging around? :)

There's a test case for this documented at:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=9565

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
I think the mistake a lot of us make is thinking the state-appointed
psychiatrist is our "friend."
------------
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: [PATCH] remote_detach() and inferior_pid
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38ABADEC.F0320CCB@cygnus.com>
References: <14505.29243.656290.516276@kwikemart.cygnus.com> <bd7pynspv.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00323.html
Content-length: 479

Jim Kingdon wrote:
> 
> > This happens because remote_detach() (and remote_async_detach()) do
> > not reset inferior_pid to 0. Is there a reason for this being this
> > way?
> 
> Setting inferior_pid to 0 sounds good.  I'm not completely sure why
> the *_detach functions don't just call generic_mourn_inferior.

Would that kill the target?  Dig dig dig.  Nope!

Yes, generic_mourn_inferior looks to be doing the correct thing - namely
pulling breakpoints and the like.

	Andrew
From mark@codesourcery.com Sat Apr 01 00:00:00 2000
From: Mark Mitchell <mark@codesourcery.com>
To: donnte@microsoft.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Regressions problem (200 failures)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000301123337B.mitchell@codesourcery.com>
References: <BB61526CDE70D2119D0F00805FBECA2F12A39A08@RED-MSG-55>
X-SW-Source: 2000-q1/msg00478.html
Content-length: 677

>>>>> "Donn" == Donn Terry <donnte@microsoft.com> writes:

    Donn> regressions pointing it at a new gcc)?  (The gcc CVS as of
    Donn> 5:30 or so PST last night still exhibited the problem.)
    Donn> Does anyone have any thougts on how to proceed?

I have one.  (I communicated this to Donn privately, so this is for
the list.)

I think GCC shouldn't put out any line notes for the prologue in the
first place.  That's what's causing the problem, indirectly.  Does GDB
require a line note in the prologue, or can we wait until the first
bit of real code?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
From khendricks@ivey.uwo.ca Sat Apr 01 00:00:00 2000
From: Kevin Hendricks <khendricks@ivey.uwo.ca>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>, Kevin Buettner <kevinb@cygnus.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: <00022221542500.09439@localhost.localdomain>
References: <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local>
X-SW-Source: 2000-q1/msg00378.html
Content-length: 2046

Hi Kevin B.

Here is my first bug report.  This is with gdb from today's cvs (after your
later commit) debugging a problem with Motif Drag-n-Drop in the jdk under
native threads.

Everything was working fine until I decided to rerun the program from within
gdb without removing my shared library breakpoints first.

Here is the resulting log file.  Notice the non-existent breakpoint 0 and also
even through I manually removed all of my breakpoints and tried to continue I
could not do so.

I hope this info helps.  The only simple test case would be to actually run the
DDTest java program under the jdk with Motif source around.

Let me know if you would like more info about this bug (explicit steps to try)
and I would be happy to follow instructions.

Thanks,

Kevin H.

Program received signal SIGINT, Interrupt.
[Switching to Thread 9456]
0xfda22c4 in __syscall_rt_sigsuspend () at soinit.c:59
59      soinit.c: No such file or directory.
(gdb) list
54      in soinit.c
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /usr/local/jdk/ucvs/jdk1.2.1/build/linux/bin/ppc/native_threads/java_g DDTest
warning: Cannot insert breakpoint 0:
Cannot access memory at address 0xfa94cdc
(gdb) c
Continuing.
warning: Cannot insert breakpoint 0:
Cannot access memory at address 0xfa94cdc
(gdb) c
Continuing.
warning: Cannot insert breakpoint 0:
Cannot access memory at address 0xfa94cdc
(gdb) del 0
warning: bad breakpoint number at or near '0'
(gdb) del 1
(gdb) del 2
(gdb) del 3
(gdb) c
Continuing.
warning: Cannot insert breakpoint 0:
Cannot access memory at address 0xfa94cdc
(gdb) info break
No breakpoints or watchpoints.
(gdb) c
Continuing.
warning: Cannot insert breakpoint 0:
Cannot access memory at address 0xfa94cdc
(gdb) 



 --
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

problems with gdb

[Chris Blizzard]

Hi, folks.  I've been talking about some problems that I've been suffering
through with gdb and mozilla which people on this mailing list may or may not
be aware of.  Jason Molenda suggested that I start flushing these out in the
open to get some feedback on them.

I'm interested in getting my hands dirty and try to get these problems fixed. 
I'm not a debugger hacker though so I might end up asking some silly
questions.  :)

Here's the blurb, slightly edited for content.

...My problems are mostly related to how well gdb scales to handle large
shared libraries and large numbers of shared libraries.  At last count, there
were 111 .so files in mozilla, the largest of which is about 27 meg with
debugging symbols.  If you don't use "set auto-solib-add 0" in your .gdbinit
file, gdb will easily grow to over 200 meg in size when starting the
debugger.  Someone once did some estimates and it seems to use 5 times the
size of a .so after loading a shared library to debug.  A lot of times, gdb
won't be able to load some of the larger .so files.  It just hangs.

A lot of times, trying to use "step" to step into a c++ method that happens to
be part of the same class just skips as if you had used "next."  That means
that any time you want to step into a method you have to set a temporary
breakpoint by name on the method and then allow the breakpoint to get you into
that method.  Doing that to step into a dozen or so classes gets a little
tedious.  This is hard to reproduce and I'm trying to build a test case.

There are other much needed features, like not being able to preload a .so and
setting a breakpoint in the library before it loads.  Mozilla is entirely
component based and this makes debugging very, very difficult.  I usually
break on _dl_open in glibc and wait until my library gets loaded before trying
to set the breakpoint that I need.  That gets pretty bad after 27 libraries
are loaded.

There are also various problems with threads.  A lot of times gdb won't exit
after the last thread exits because it keeps trying to kill a process which
doesn't exist any more.

We've got a deubugging FAQ that tries to show ways to work around deficencies
in the deubugger:

http://www.mozilla.org/unix/debugging-faq.html

There are a lot of people who work at Netscape who would be using Linux as
their primary platform if, and I'm quoting here, "using gdb wasn't like
scratching your own eyes out."  This is one of the reasons why Mozilla is so
much slower on Linux than it is on windows.  People waste so much time
debugging on it that they just give up.

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
I'm not into working out. My philosophy: No pain, no pain.
------------
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: Andrew Cagney <ac131313@cygnus.com>, Mark Kettenis <kettenis@wins.uva.nl>, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C84793.8E138624@apple.com>
References: <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com> <38C82D34.31E36610"@cygnus.com> <20000309153922.A8624@lucon.org>
X-SW-Source: 2000-q1/msg00666.html
Content-length: 1864

"H . J . Lu" wrote:

> > A GNU/Linux distributor is free to build a GDB that regexp from an
> > installed glibc. Actually such a distributor is free to do what ever
> > they like :-)
> 
> Are you saying as far as gdb is concerned, you have no interests
> whatsoever in glibc nor helping glibc developers and GNU/Linux
> distributors? If it is true, that is too bad.

Let's not get all tense here!  There's a balance to be struck between
being self-contained and depending on system stuff, and there's no
single rule that applies in all cases.  For instance, GDB includes
libiberty, even though many of the functions are available on most
systems by default, including Linux, but I don't seem to hear anybody
complaining about that bit of redundancy.  (Hmmm, why isn't regex
in libiberty anyway??)

In the case of GDB on Linux, part of our problem is that we have
to support GDB on all versions of Linux, not just the latest
kernel and library.  So if there is *any* version of glibc with
a problematic regex, say one from 4-5 years ago, we need to think
hard about whether we're going to hose people running a Linux that
is that old.  GDB's rule has been to maximize compatibility with
a whole range of OS versions, and now that Linux has sailed past all
other OSes in number and variety of versions, it's really putting
our infrastructure to the test.

In this case, my inclination would be to rely on the glibc regex
by default.  GDB users don't tend to push the boundaries of regexps
in their daily debugging activities, and if recent glibcs are good,
then it's seems unlikely that we'll ever get any bug reports
stemming from regex problems.  So we'll be taking a bit of a chance,
but with the configuration option, and if we communicate to the glibc
folks that we're now always depending on their version to be correct,
I think things will work out OK.

Stan
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A revised patch for dlclose
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307170321.A884@lucon.org>
References: <20000307120800.A27315@valinux.com> <200003080058.e280wga00453@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00579.html
Content-length: 1258

On Wed, Mar 08, 2000 at 01:58:42AM +0100, Mark Kettenis wrote:
>    Date: Tue, 7 Mar 2000 12:08:00 -0800
>    From: "H . J . Lu" <hjl@valinux.com>
> 
>    Here is a revised patch for dlclose. If you take a look at the
>    dynamic linker in glibc 2.1 or above, you will find that it informs
>    gdb about loading/unloading a shared library via an internal debug
>    function, _dl_debug_state (). gdb already handles the loading in
>    handle_inferior_event () with BPSTAT_WHAT_CHECK_SHLIBS and
>    BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK. However, we need also
>    check the unloading event. solib_verify () will be called only when the
>    dynamic linker calls _dl_debug_state (). It shouldn't introduce any
>    overhead. I believe it is on the right track although it may be further
>    optimized.
> 
> HJ, please stop wasting your time pushing this patch.  The patch has
> several bad points, that you cannot fix without considerable changes
> to the way solib.c handles and caches the link map.

I just pointed out gdb needed to check the unloaded DSOs when handling
the BPSTAT_WHAT_CHECK_SHLIBS and BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK
events. It is a serious bug to me and it should be fixed in 5.0. I
don't care how it is fixed.


H.J.
From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Pascal language support patch preparation
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003021347.OAA01051@cerbere.u-strasbg.fr>
References: <200003021257.NAA00259@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00500.html
Content-length: 2092

At 14:21 02/03/00 +0100, you wrote:
>   Date: Thu, 02 Mar 2000 13:41:58 +0100
>   From: Pierre Muller <muller@cerbere.u-strasbg.fr>
>
>      I want to format my PATCH for pascal extension before submitting it 
>   so I read that I should use GNU indent with -gnu option !
>
>Hi Pierre, I do hope that you'll break your patch up in some smaller
>chunks.  IMHO the fact that you sent it as a large chunk, was one of
>the main reasons why it was ignored last fall.  

  But adding a new language means at least :
new files :
  p-lang.h p-lang.c p-valprint.c p-typeprint.c and p-exp.y
plus the changes needed to make GDB know about pascal language !
This means a bunch of other changes of course !

>     But I tried this on c-lang.h just to see
>   and the result is that the current header file does not conform to 
>   indent output !
>
>Looks like you're using a different `indent' than was used on the GDB
>sources.  I think, this shows that defining the GDB coding standards
>in terms of the output of `indent' is not really workable.  I've also
>noticed that `indent' sometime really messes up the output, because it
>gets confused by certain constructs.

indent --version gives "GNU indent 2.2.5"
is that not the current version ??

>     So my question is simply should I run indent on my files
>   or should I send them without !
>
>I'd say that avoiding gratuitous reformatting is more important than
>running your changes through `indent'.  Thus, make sure that your
>patches only contains changes for code you really changed, and that
>these changes correspond to the GNU coding standards.

  One of the main problem is that my patches are primarily 
files c-*.* first copied to p-*.* then adapted to reflect pascal instead of C,
but of course this copy was primarily done on v4.17 !
I change after so that it compiled with v4.18, but
all the changes  made in c-*.* since then are not in my pascal files.



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From jlarmour@redhat.co.uk Sat Apr 01 00:00:00 2000
From: Jonathan Larmour <jlarmour@redhat.co.uk>
To: gdb@sourceware.cygnus.com
Subject: copyright banner and reporting bugs
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CFF922.6BA6928E@redhat.co.uk>
X-SW-Source: 2000-q1/msg00712.html
Content-length: 570

I just noticed two minor things: surely the copyright banner when GDB starts
should be something more recent than 1998 even now - i.e. it shouldn't need
to wait for the release.

Also on http://sourceware.cygnus.com/gdb it isn't at all clear how users
report bugs. This is worthy of a section in its own right surely! Just an
appropriate regurgitation of the info file node from gdb.texinfo would be
enough.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault
From toddpw@windriver.com Sat Apr 01 00:00:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: gdb@sourceware.cygnus.com (GDB Developers)
Subject: Readline and -DMINIMAL
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003281230.EAA15638@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00823.html
Content-length: 673

I have just discovered to my horror that the upgrade to Readline 2.2 in
GDB 4.18 has completely eradicated support for the MINIMAL #define, and
provides no alternative -- it simply assumes BSD style ttys and falls
over dead if those aren't supported.

Does anyone know the story on this one?  Is there a stub library that
is used for Cygwin and DJGPP ?  I noticed a specific hack for cygwin
that simply assumes libtermcap.a, I suppose this is a B20 invention.

I really do not want to hack all the #ifdef MINIMAL stuff back in, but
since I build direct on windows I need to shut up all the code that tries
to use sgtty or termios.

-- 
Todd Whitesel
toddpw @ windriver.com
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jtc@redback.com
Cc: eliz@is.elta.co.il, gdb@sourceware.cygnus.com
Subject: Re: Running the inferior from breakpoint commands
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003162229.e2GMTda00304@delius.kettenis.local>
References: <200003120759.CAA24402@indy.delorie.com> <5mem9ad1vw.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00724.html
Content-length: 584

   From: jtc@redback.com (J.T. Conklin)

   Eli> The DJGPP version seems to behave like HPPA (I'm not sure whether this
   Eli> is a compliment, and if so, to which of the two systems ;-).  However,
   Eli> I stepped through the code that is involved, and I don't see anything
   Eli> DJGPP-specific there.

   It's been a while, but if I remember correctly, this test failed when
   I ran the testsuite on NetBSD/i386.  It appeared that someone changed
   the testsuite to match HPUX's behavior instead of letting the test fail.

The test fails on the Hurd and Linux/i386 too.

Mark
From akale@veritas.com Sat Apr 01 00:00:00 2000
From: "Amit S. Kale" <akale@veritas.com>
To: Todd Whitesel <toddpw@windriver.com>, kingdon@redhat.com (Jim Kingdon)
Cc: akale@veritas.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Regression caused by elfread.c patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <00021514224700.31608@fermat.vxindia.veritas.com>
References: <200002150800.AAA07477@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00291.html
Content-length: 2745

Hi,

On Tue, 15 Feb 2000, Jim Kingdon wrote:
> > That was because Jim didn't checkin my patch correctly.
> > He has fixed it now.
> 
> No, this is a different problem.

Apolgies to Jim, because the problem was not his fault as said by me.

> I don't see how your patch could work at all - sym->section->index is
> a very different number than a SECT_OFF_* code.  The SECT_OFF_* code
> (which gets fed to ANOFFSET) isn't computed until later in the
> function (via the call to record_minimal_symbol_and_info).

The patch I sent is working in some configurations. I have been using it for
debugging linux kernel. This patch was needed to load module object files using
'add-symbol-file' after loading kernel object file using 'symbol-file'.

I guess gdb first prepares text, data, bss segments and following code
bfd/section.c:bfd_make_section_anyway():
	newsect->index = abfd->section_count++;
indicates that section->index contains SECT_OFF_* codes when segments are
loaded. This may not have been designed this way, but it seems to be that way.

Using sym->section->index is not right for segments that are not text or data
segments. Using sym->section->index should be all right for data segments.

I suggest following patch. I have verified that the vfprintf problem reported
by Mark does not appear with this patch. I haven't tested it with test suite.

--- elfread.c   Tue Feb 15 13:54:52 2000
+++ ../../../utils/src/gdb/elfread.c    Tue Feb 15 10:56:30 2000
@@ -293,14 +293,11 @@ elf_symtab_read (objfile, dynamic)
       if (number_of_symbols < 0)
        error ("Can't read symbols from %s: %s", bfd_get_filename (objfile->obfd),
               bfd_errmsg (bfd_get_error ()));
+      /* FIXME: Should use section specific offset, not SECT_OFF_TEXT. */
+      offset = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT);
       for (i = 0; i < number_of_symbols; i++)
        {
          sym = symbol_table[i];
-         if (sym->section->flags & SEC_DATA) {
-                 offset = ANOFFSET (objfile->section_offsets, sym->section->index);
-         } else {
-                 offset = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT);
-         }
          if (sym->name == NULL || *sym->name == '\0')
            {
              /* Skip names that don't exist (shouldn't happen), or names 


On Tue, 15 Feb 2000, Todd Whitesel wrote:
> [snip]
> However, so few configurations (read: vxWorks and ??) actually use different
> offsets for, say, SECT_OFF_TEXT and SECT_OFF_DATA, that no one notices the
> problems with it. (We read relocatable .o files too, which is also rare.)

It won'd be rare when gdb will be used by more people to debug linux kernel
modules.
> [snip]


-- 
Amit Kale
Veritas Software ( http://www.veritas.com )
From hjl@valinux.com Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: GDB <gdb@sourceware.cygnus.com>
Subject: Today's gdb broken on Linux/ia32
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307141732.A21740@valinux.com>
X-SW-Source: 2000-q1/msg00567.html
Content-length: 255

With today's gdb from CVS, I got:

# /work/build/gnu/bin/gdb.orig/gdb/gdb ex1
(gdb) r
Starting program: /work/build/gnu/bin/glibc-2.1.old/linuxthreads/ex1 
[New Thread 1024 (runnable)]

ex1 is from linuxthreads in glibc 2.1.3.


-- 
H.J. Lu (hjl@gnu.org)
From qqi@world.std.com Sat Apr 01 00:00:00 2000
From: Quality Quorum <qqi@world.std.com>
To: gdb@sourceware.cygnus.com
Subject: Z-protocol errors and limts
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.SGI.3.95.1000125201837.17703B-100000@world.std.com>
X-SW-Source: 2000-q1/msg00056.html
Content-length: 529

Hi, 

I have a few questions related to Z-protocol on implmentation
on the stub side:

1. How many soft break point has to be supported ?

2. How stub tells gdb that it run out of soft break points ?

3. If stub supports soft break points but does not support
   hw (or some of hw break points), how it tells gdb about it ?

I suppose that all thesecurrenly are errors and it is a responsibility 
of the gdb to not blow out any limits. However, I did not see
any specification limiting number of soft breaks.

Thanks,

Aleksey

Re: problems with gdb

[Chris Blizzard]

Mark Kettenis wrote:
> 
> I cannot reproduce this (in both cases).  This might be caused by the
> fact that I am running a glibc-2.1.3 snapshot (which includes the
> libthread_db.so.1 debugging library).  Or my machine isn't fast enough
> to show the problem :-(.

When you say "in both cases" do you mean with and without the patch?  I have
that on my system, too.  Is there anything special I have to do to use it?

--Chris


-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
I think the mistake a lot of us make is thinking the state-appointed
psychiatrist is our "friend."
------------
From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: gdb@sourceware.cygnus.com
Subject: Re: Buffering problems with "gdb < foo"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003070845.JAA27855@cerbere.u-strasbg.fr>
References: <14531.61750.823726.628635@kwikemart.cygnus.com> <200003050850.DAA10185@indy.delorie.com>
X-SW-Source: 2000-q1/msg00556.html
Content-length: 1177

At 03:17 07/03/00 -0500, Eli Zaretskii wrote:
>
>>  > Does this work on Unix?  If so, it would make this a DJGPP-specific
>>  > problem.
>> 
>> I haven't tried, but probably it won't. Can you send me your command file?
>
>It is simply "gdb < foo > bar".  The input file `foo' looks like this:
>
>  shell gcc -g -o t.exe t.c
>  file t.exe
>  dir
>  y

  dir needs no confirmation if not invoked from tty !
look into directory_command source :
void
directory_command (dirname, from_tty)
     char *dirname;
     int from_tty;
{
  dont_repeat ();
  /* FIXME, this goes to "delete dir"... */
  if (dirname == 0)
    {
      if (from_tty && query ("Reinitialize source path to empty? "))
	{
	  free (source_path);
	  init_source_path ();
	}
    }

>  dir .
>  break main
>  run
>  q
>  y
>
>(If needed, I can send the exact file used for the input.)  Try this,
>and you will see that GDB exits immediately after it processes the
>first "dir" command.

I think its because y is not a valid GDB command !




Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Dependence on config.status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C0ACF2.C00719B0@cygnus.com>
References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> <bem9u49sh.fsf@rtl.cygnus.com> <200003021007.FAA04124@indy.delorie.com>
X-SW-Source: 2000-q1/msg00538.html
Content-length: 363

Eli Zaretskii wrote:
> 
> > Well, if memory serves, if you re-ran configure in such a way that
> > tm.h started linking to a different file, then the config.status
> > dependency was the only way to force a rebuild.
> 
> How about adding some #define to config.h that would also change when
> this happens?

Such as the names of the tm, xm and nm files?

	Andrew
From leedh@cs.hongik.ac.kr Sat Apr 01 00:00:00 2000
From: leedh <leedh@cs.hongik.ac.kr>
To: gdb@sourceware.cygnus.com
Subject: Question.....
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E1B5BA.C555471B@cs.hongik.ac.kr>
X-SW-Source: 2000-q1/msg00835.html
Content-length: 490

Hi...

Our Host system environment is connectted to target system by serial
port.

We had loaded VxWorks RTOS into your EBSA-285 Board for testing.

Now, We are willing to connect cygnus GNU debugger toolkit(host
system-window NT)

to angel debugger on EBSA-285 Board(target system-strongArm).

But, cygnus debugger isn't connectted to target system.

Please, You advise in this problem for me.

If possible, I want Document / Install file .

Sorry, I'm a little English.

Thank You.

Re: problems with gdb

[Eli Zaretskii]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 11002 bytes --]

On Sun, 10 Dec 2000, Bernd K. wrote:

> i can't debug my programs. If i write "gdb program" and then for 
> instance "list" it returns
> "init.c no such file or directory".
> What's wrong?

This happens when GDB cannot find the sources for your program.  Is 
init.c in the same directory where you run GDB?  If not, you can add 
any directory FOO to the list of directories where GDB looks for sources 
by typing "dir FOO" at the GDB prompt.  You can add several directories 
with several `dir' commands, or by typing a list of directories separated 
by a semi-colon.

Do that _before_ the first `list' command.
From joel.sherrill@OARcorp.com Mon Dec 11 13:27:00 2000
From: Joel Sherrill <joel.sherrill@OARcorp.com>
To: gdb@sources.redhat.com, newlib@sources.redhat.com, crossgcc@sources.redhat.com
Subject: tx39 simulator timer questions
Date: Mon, 11 Dec 2000 13:27:00 -0000
Message-id: <3A3545D6.6137C189@OARcorp.com>
X-SW-Source: 2000-12/msg00065.html
Content-length: 1519

Hi,

I hate to crosspost like this but I need to find someone who is
knowledgeable about the TX3904 and/or its simulator in gdb.  

I now have a simple RTEMS board support package (supports hello world)
running on it.  I want to use one of the 3 timers in interval mode 
to generate a clock tick. 

But between an error reading the PDF Toshiba documentation :)
and the simulator, I am confused about the requirements/sequence 
to make the timer do this.  Comments in dv-tx3904tmr.c indicate
that it does not support level triggered interrupts.

So far I have this as initialization:

  ILR3 = 0x00000700;  make timer0 level 7
  CCDR = 0x3;         divide by 16
  CPRA = <clicks>;    value in compare register
  TISR = 0x00;        clear all pending interrupts
  TCR  = 0xC0;        interval mode, internal system clock, enabled
  ITMR = 0x8001;      enable it, make it periodic

I think I may need to also deal with the CConR register.

??? What is the simulated clock speed when --board=jmr3904???
It is hard to know what is a meaningful value for CPRA.

I have tried to enable debug in the simulator (configured
with --enable-sim-debug) to see more of what was happening
but that resulted in gdb 5.0 not building.

Advice on the tx39 and/or the simulator is appreciated.

Thanks.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985
From jtc@redback.com Mon Dec 11 15:21:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Stephane Carrez <ciceron@sunchorus.France.Sun.COM>
Cc: gdb@sourceware.cygnus.com
Subject: Re: additional vector function to improve  register fetch performance
Date: Mon, 11 Dec 2000 15:21:00 -0000
Message-id: <5mhf4apmry.fsf@jtc.redback.com>
References: <200012081053.LAA22829@sunchorus.France.Sun.COM>
X-SW-Source: 2000-12/msg00066.html
Content-length: 6439

>>>>> "Stephane" == Stephane Carrez <ciceron@sunchorus.France.Sun.COM> writes:
>> While we're talking about register fetch and stores, I had an idea the
>> outher night about improving performance by adding some new functions
>> to the target vector.

Stephane> For gdb for ChorusOS (system debug), I'm doing some prefetch
Stephane> to improve performance. For each processor, I've defined a
Stephane> list of "gdb important registers". I retreive the complete
Stephane> list when gdb asks for one of them.
Stephane>
Stephane> For example for Sparc, I've defined the following list:
Stephane>
Stephane>  	sp, pc, rp, fp
Stephane>
Stephane> So, when gdb asks for either sp or pc, I retreive these 4
Stephane> registers.
Stephane>
Stephane> In general, I've observed this is enought. For most
Stephane> processors Gdb needs the sp, pc and fp (in general after
Stephane> each stop). I'm using this for sparc, x86 and ppc.

I know well that providing a handful of registers can dramatically
improve performance.  

The GDB remote protocol has a mechanism such that that the values of
key registers can be returned along with the exception/signal number
whenever execution stops.  Long ago I submitted a patch to add the pc,
sp, and fp to the sample i386 and m68k stubs.  I don't know what ever
happened to it, I should probably dust it off and submit it again.

I'm not sure that your suggestion to prefetch all "gdb important
registers" when any in that set are read is generally applicable.
While this kind of optimization can be done in the target layer
reasonably easily for those GDB targets that are only used by one
target system, it is much more difficult for GDB targets that are
"generic" like remote.c.

One problem is that this breaks the abstraction layer between target-
independent and target specific code.  I admit that this is a fuzzy
line, but having remote.c (for example) know about "important regs"
clearly breaks it (IMO).

Another problem is that the target layer doesn't know what registers
are already stored in the regcache.  This would require additions to
the regcache API so it could be queried so that only those registers
that needed to be fetched would be.

Finally, this would have to be added to more than one target.  IMO,
this makes it clear that a mechanism for handling "important regs" in
the target layer is flawed.  If the idea is pursued, it belongs above
the target layer.  This would make a fetch of any of the "important
regs" a prefetch for all of the others in the set.

This could be implemented reasonably cleanly, and does not suffer from
the problem you alluded elsewhere in your response that you don't know
when a register is going to be needed.  Adding a bunch of explicit pre-
fetch hints may not help if you miss one critical one.  

But I still think that there needs to be some way for GDB to tell the
target layer that more than one register is going to be fetched.  It
won't matter for those targets that fetch all registers at once or
those that can only fetch one at a time, but those that can fetch a
arbitrary set (or even those that can both fetch all and fetch one)
can't take advantage of that unless it knows what registers will be
fetched.  Otherwise the latency of a full register set fetch or
multiple single register fetches is still a problem.  

>> * target_prefetch_register()
>> 
>> With the register cache and targets that always fetch the entire
>> register set, fetch performance is as good as can be expected.  But
>> with a target that can fetch one register at a time, GDB will issue
>> multiple single register fetches.  Due to command/response latency,
>> this has a significant performance impact.
>> 
>> One way this could be addressed is to always fetch the entire
>> register set.  The remote protocol is like this, while it can set a
>> single register, there is no command to fetch one.  This approach
>> may lose when the register set is large and the number of registers
>> to be fetched is small; it may be possible to issue several single-
>> register fetches in the time for one for the entire register set.

Stephane> Fetching all registers is a killer for PPC... In general,
Stephane> only the pc, lr and sp are used by Gdb (ok, except for
Stephane> arguments/locals).

This would be a problem even if there the remote protocol supported a
read-single register command, since GDB would fetch for each register
sequentially.  Whether to fetch the entire set or a fetch individual
registers depends on many factors: the number of registers, the size
of the register set, the bandwidth and latency of the debug channel.

Fortunately, as I mentioned earlier, the remote protocol allows for
register values to be returned when execution stops.  Before I added
support to our powerpc stub, "step", "next", etc. were painful.  To
be perfect, GDB needs to be able to take advantage of a step-out-of-
range command; but that's a different project.

Stephane> I like the idea of pre-fetching but I wouldn't introduce a
Stephane> new target vector for that. The 'prefetch_reg' is somewhat
Stephane> generic. We just have to keep a list of registers that will,
Stephane> soon, be required.
Stephane>
Stephane> Then, when we really need a register, the
Stephane> target_fetch_register() can look at the prefetch list that
Stephane> was built. It can then retrieve all of them depending on the
Stephane> remote protocol.

Until this moment, I've assumed that your implementation was in the
target layer.  But I've just reread your message and noticed that you
didn't say that.  In fact, it appears we've come to many of the same
conclusions.

One difference is that in my scheme, the target layer is explicitly
given prefetch hints and in yours the target layer accesses the hints
that are maintained above.  I'm not especially fond of either.  In my
scheme, each target must maintain its own infrastructure for recording
the prefetch list.  In yours, the target reaches above to get the list.
Perhaps the interface to target_fetch_registers() should be changed to
include a vector containing all the registers to be fetched.

Stephane> The "gdb important registers" approach is interesting in
Stephane> that it gives good performance win and does not need to add
Stephane> the pre-fetch hints.

Many thanks for your comments.  I'm not ready to act on this yet, but
I'm better off now than when I was before.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From info@cavasdevinos.com Mon Dec 11 15:34:00 2000
From: info <info@cavasdevinos.com>
To: <gdb@sourceware.cygnus.com>
Subject: Navidad, Alegria y Vinos
Date: Mon, 11 Dec 2000 15:34:00 -0000
Message-id: <5a6b74ff8e35ea9aa6aec34aff02430c@NO-ID-FOUND.mhonarc.org>
X-SW-Source: 2000-12/msg00067.html
Content-length: 1295

Obtenga un 50% de descuento en toda la linea de productos de Finca Flichman.
Llevese otra botella de regalo por cada una que compre de Bodegas Nanni.

Se lanza al mercado http://www.cavasdevinos.com portal que tiene la referencia 
de todas las bodegas y sus productos, usted podra elegir y comprar el que mas 
se adapte a su gusto, se lo entregaremos donde decida a la brevedad.

Victor Baron, hombre de vinos y bebidas espirituosas, formado entre aromas y 
texturas, lanza al mercado su portal de vinos donde podra buscar el suyo entre 
todos.

Todas las bodegas todas las marcas, con su explicacion tecnica, su recomendacion 
y la de los mejores catadores.

Elija usted, y sumerjase en la aventura de disfrutar su eleccion o dejese llevar 
por un consejo y tenga luego su propio juicio que servira para otro momento.

Es un lanzamiento del grupo Overseas Traiding, respaldo tecnologico de Moore 
Stephens Intl.

NOTA: Bajo el decreto S.1618 titulo 3ro. Aprobado por el 105 congreso base de 
las normativas internacionales sobre SPAM, este E-mail no podrá ser considerado 
SPAM mientras incluya una forma
de ser removido. Si por cualquier motivo no desea recibir esta lista periódicamente, 
por favor haga un reenvio y coloque en el asunto REMOVER a esta direccion: remover@cavasdevinos.com