Re: problems with gdb

[Chris Blizzard <blizzard@redhat.com>]

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.