public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: debug/8095: missing dwarf info for parent class
@ 2002-10-01 12:16 Daniel Jacobowitz
0 siblings, 0 replies; 13+ messages in thread
From: Daniel Jacobowitz @ 2002-10-01 12:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR debug/8095; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: Horsley Tom <Tom.Horsley@ccur.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Tue, 1 Oct 2002 15:06:44 -0400
On Tue, Oct 01, 2002 at 08:02:44AM -0400, Horsley Tom wrote:
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@mvista.com]
> > Sent: Monday, September 30, 2002 4:38 PM
> > To: tom.horsley@ccur.com
> > Cc: gcc-gnats@gcc.gnu.org
> > Subject: Re: debug/8095: missing dwarf info for parent class
> >...
> > Please provide a test case.
>
> Weird. Every program I have exhibits this behavior. Here's
> a random test program I picked this morning on my first try :-).
>
> class Vtab1 {
> public:
> Vtab1();
> Vtab1(int init_x);
> virtual
> ~Vtab1();
> virtual int
> GetX();
> private:
> int x;
> };
> class Vtab2 {
> public:
> Vtab2();
> Vtab2(int init_y);
> virtual
> ~Vtab2();
> virtual int
> GetY();
> private:
> int y;
> };
> class Multiple1 : public Vtab1, public Vtab2 {
> public:
> Multiple1(int init_x, int init_y, int init_z);
> virtual
> ~Multiple1();
> virtual int
> GetZ();
> private:
> int z;
> };
> class Derived1 : public Multiple1 {
> public:
> Derived1(int init_x, int init_y, int init_z);
> virtual
> ~Derived1();
> virtual int
> GetX();
> private:
> int my_x;
> };
> Derived1::Derived1(int init_x, int init_y, int init_z)
> : Multiple1(init_x, init_y, init_z) {
> my_x = GetY();
> }
> Derived1::~Derived1() {
> return;
> }
> int
> Derived1::GetX() {
> return my_x;
> }
>
> Using g++ 3.2 (Red Hat Linux Rawhide 3.2-1), if I compile
> this as g++ -g -c d1.cpp and examine the dwarf in the d1.o file,
> no symbols named "x","y", or "z" appear anywhere, and the
> parent class info for Derived1 points to a DW_AT_declaration
> for Multiple1, but there is no corresponding class definition
> with a DW_AT_specification pointing to that Multiple1, so
> no definition is available anywhere for the actual contents
> of the parent classes, yet they are certainly used since
> the type of the "this" pointer in the member functions
> refers to them indirectly.
OK. The reason that debug info for (for example) Vtab1 is not emitted
is because it contains unimplemented virtual functions which are not
declared as abstract. Thus the vtable for Vtab1 is not emitted, and
the debug information appears to be tied to that.
I could make a good argument that this isn't right. Can a C++
maintainer comment?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: debug/8095: missing dwarf info for parent class
@ 2003-04-15 15:05 bangerth
0 siblings, 0 replies; 13+ messages in thread
From: bangerth @ 2003-04-15 15:05 UTC (permalink / raw)
To: drow, gcc-bugs, gcc-prs, tom.horsley
Synopsis: missing dwarf info for parent class
State-Changed-From-To: feedback->closed
State-Changed-By: bangerth
State-Changed-When: Tue Apr 15 15:05:13 2003
State-Changed-Why:
Seems as if we came to a conclusion
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8095
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: debug/8095: missing dwarf info for parent class
@ 2003-04-15 13:36 Daniel Jacobowitz
0 siblings, 0 replies; 13+ messages in thread
From: Daniel Jacobowitz @ 2003-04-15 13:36 UTC (permalink / raw)
To: drow; +Cc: gcc-prs
The following reply was made to PR debug/8095; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: gcc-bugs@gcc.gnu.org, tom.horsley@ccur.com, gcc-gnats@gcc.gnu.org
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Tue, 15 Apr 2003 09:35:43 -0400
On Fri, Mar 14, 2003 at 03:58:32PM -0600, Wolfgang Bangerth wrote:
>
> > > If there are ways to tie debug output to a certain member of a class (just
> > > as we do for vtables), then I would say this is a good idea. If someone
> > > doesn't like this, then compile your library with -g.
> >
> > I guess that sounds pretty reasonable to me, too.
>
> So shall I close the report then? Note that I couldn't verify that the
> debug info is actually emitted when the vtable is emitted -- could you
> check this?
Yes, when the vtable is emited the debug information is also. I think
we can close this PR.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: debug/8095: missing dwarf info for parent class
@ 2003-03-17 14:26 Daniel Jacobowitz
0 siblings, 0 replies; 13+ messages in thread
From: Daniel Jacobowitz @ 2003-03-17 14:26 UTC (permalink / raw)
To: drow; +Cc: gcc-prs
The following reply was made to PR debug/8095; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: Horsley Tom <Tom.Horsley@ccur.com>
Cc: Wolfgang Bangerth <bangerth@ticam.utexas.edu>, gcc-bugs@gcc.gnu.org,
gcc-gnats@gcc.gnu.org
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Mon, 17 Mar 2003 09:18:29 -0500
On Mon, Mar 17, 2003 at 07:59:02AM -0500, Horsley Tom wrote:
> > > If there are ways to tie debug output to a certain member of a class
> (just
> > > as we do for vtables), then I would say this is a good idea. If someone
> > > doesn't like this, then compile your library with -g.
> > >
> > > But that's just my opinion.
> >
> > I guess that sounds pretty reasonable to me, too.
>
> I'm not sure the intent of my original bug report made it through
> this discussion :-). I don't see why you'd always have to emit
> debug info for every header file in every compilation unit.
> Just emit debug info for types that are "used". The point of the
> bug report was to say that the "this" variable should count
> as "using" a type, and if a derived class is "used", then all its
> base classes should be "used" as well (after all, there isn't
> all that much difference between a base class and a member variable,
> and you wouldn't leave out member variables just because they
> weren't directly referenced would you?).
>
> Of course I say this is total ignorance of how gcc decides to emit
> debug info :-).
The problem is that this causes debug info for that class to be emitted
multiple times. If you compile the source file that causes the base
class to be emitted - there must be one, or your program won't link -
then that file should have the debug info.
I still need to verify that it' being output in the right place.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: debug/8095: missing dwarf info for parent class
@ 2003-03-17 13:06 Horsley Tom
0 siblings, 0 replies; 13+ messages in thread
From: Horsley Tom @ 2003-03-17 13:06 UTC (permalink / raw)
To: drow; +Cc: gcc-prs
The following reply was made to PR debug/8095; it has been noted by GNATS.
From: Horsley Tom <Tom.Horsley@ccur.com>
To: 'Daniel Jacobowitz' <drow@mvista.com>, Wolfgang Bangerth
<bangerth@ticam.utexas.edu>
Cc: gcc-bugs@gcc.gnu.org, Horsley Tom <Tom.Horsley@ccur.com>,
gcc-gnats@gcc.gnu.org
Subject: RE: debug/8095: missing dwarf info for parent class
Date: Mon, 17 Mar 2003 07:59:02 -0500
> > If there are ways to tie debug output to a certain member of a class
(just
> > as we do for vtables), then I would say this is a good idea. If someone
> > doesn't like this, then compile your library with -g.
> >
> > But that's just my opinion.
>
> I guess that sounds pretty reasonable to me, too.
I'm not sure the intent of my original bug report made it through
this discussion :-). I don't see why you'd always have to emit
debug info for every header file in every compilation unit.
Just emit debug info for types that are "used". The point of the
bug report was to say that the "this" variable should count
as "using" a type, and if a derived class is "used", then all its
base classes should be "used" as well (after all, there isn't
all that much difference between a base class and a member variable,
and you wouldn't leave out member variables just because they
weren't directly referenced would you?).
Of course I say this is total ignorance of how gcc decides to emit
debug info :-).
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: debug/8095: missing dwarf info for parent class
@ 2003-03-14 22:06 Wolfgang Bangerth
0 siblings, 0 replies; 13+ messages in thread
From: Wolfgang Bangerth @ 2003-03-14 22:06 UTC (permalink / raw)
To: drow; +Cc: gcc-prs
The following reply was made to PR debug/8095; it has been noted by GNATS.
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gcc-bugs@gcc.gnu.org, <tom.horsley@ccur.com>, <gcc-gnats@gcc.gnu.org>
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Fri, 14 Mar 2003 15:58:32 -0600 (CST)
> > If there are ways to tie debug output to a certain member of a class (just
> > as we do for vtables), then I would say this is a good idea. If someone
> > doesn't like this, then compile your library with -g.
>
> I guess that sounds pretty reasonable to me, too.
So shall I close the report then? Note that I couldn't verify that the
debug info is actually emitted when the vtable is emitted -- could you
check this?
Thanks
Wolfgang
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ticam.utexas.edu
www: http://www.ticam.utexas.edu/~bangerth/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: debug/8095: missing dwarf info for parent class
@ 2003-03-14 21:56 Daniel Jacobowitz
0 siblings, 0 replies; 13+ messages in thread
From: Daniel Jacobowitz @ 2003-03-14 21:56 UTC (permalink / raw)
To: drow; +Cc: gcc-prs
The following reply was made to PR debug/8095; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: gcc-bugs@gcc.gnu.org, tom.horsley@ccur.com, gcc-gnats@gcc.gnu.org
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Fri, 14 Mar 2003 16:51:45 -0500
On Fri, Mar 14, 2003 at 03:48:12PM -0600, Wolfgang Bangerth wrote:
>
> > As I mentioned, I'd like more opinions...
>
> Sorry, I understood this but just wanted to raise the issue again --
> opinions will not come in if the question bitrots in gnats :-) (Which is
> not your fault -- you had asked, but received no answers.)
>
> > what if the class is emitted
> > in a shared library not compiled using debug info, etc.? I guess the
> > question is: we want to emit debug information for all used types.
> > Does inheriting from a type count as using it? If so we should
> > probably be emitting debug info for Multiple1 in the example in this
> > PR.
>
> This doesn't strike me as a particularly useful idea, since then you would
> have to emit debug info in every compilation unit that includes a certain
> header file. This might be a lot of duplication.
>
> If there are ways to tie debug output to a certain member of a class (just
> as we do for vtables), then I would say this is a good idea. If someone
> doesn't like this, then compile your library with -g.
>
> But that's just my opinion.
I guess that sounds pretty reasonable to me, too.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: debug/8095: missing dwarf info for parent class
@ 2003-03-14 21:56 Wolfgang Bangerth
0 siblings, 0 replies; 13+ messages in thread
From: Wolfgang Bangerth @ 2003-03-14 21:56 UTC (permalink / raw)
To: drow; +Cc: gcc-prs
The following reply was made to PR debug/8095; it has been noted by GNATS.
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gcc-bugs@gcc.gnu.org, <tom.horsley@ccur.com>, <gcc-gnats@gcc.gnu.org>
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Fri, 14 Mar 2003 15:48:12 -0600 (CST)
> As I mentioned, I'd like more opinions...
Sorry, I understood this but just wanted to raise the issue again --
opinions will not come in if the question bitrots in gnats :-) (Which is
not your fault -- you had asked, but received no answers.)
> what if the class is emitted
> in a shared library not compiled using debug info, etc.? I guess the
> question is: we want to emit debug information for all used types.
> Does inheriting from a type count as using it? If so we should
> probably be emitting debug info for Multiple1 in the example in this
> PR.
This doesn't strike me as a particularly useful idea, since then you would
have to emit debug info in every compilation unit that includes a certain
header file. This might be a lot of duplication.
If there are ways to tie debug output to a certain member of a class (just
as we do for vtables), then I would say this is a good idea. If someone
doesn't like this, then compile your library with -g.
But that's just my opinion.
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ticam.utexas.edu
www: http://www.ticam.utexas.edu/~bangerth/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: debug/8095: missing dwarf info for parent class
@ 2003-03-14 21:36 Daniel Jacobowitz
0 siblings, 0 replies; 13+ messages in thread
From: Daniel Jacobowitz @ 2003-03-14 21:36 UTC (permalink / raw)
To: drow; +Cc: gcc-prs
The following reply was made to PR debug/8095; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
nobody@gcc.gnu.org, tom.horsley@ccur.com, gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Fri, 14 Mar 2003 16:33:41 -0500
On Fri, Mar 14, 2003 at 09:19:18PM -0000, bangerth@dealii.org wrote:
> Synopsis: missing dwarf info for parent class
>
> Responsible-Changed-From-To: unassigned->drow
> Responsible-Changed-By: bangerth
> Responsible-Changed-When: Fri Mar 14 21:19:17 2003
> Responsible-Changed-Why:
> Analyzed this PR
> State-Changed-From-To: open->feedback
> State-Changed-By: bangerth
> State-Changed-When: Fri Mar 14 21:19:17 2003
> State-Changed-Why:
> Daniel, what's the state of this? If debug generation is
> really tied to the definition of the first virtual non-
> abstract function, then I can't see how this could be
> wrong: no program can be linked without having such a
> definition, so at one point or other, a definition has to
> be given, and then the executable also contains the debug
> information. Unfortunately, my versions of readelf seems
> to be too old to verify this myself.
As I mentioned, I'd like more opinions... what if the class is emitted
in a shared library not compiled using debug info, etc.? I guess the
question is: we want to emit debug information for all used types.
Does inheriting from a type count as using it? If so we should
probably be emitting debug info for Multiple1 in the example in this
PR.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: debug/8095: missing dwarf info for parent class
@ 2003-03-14 21:19 bangerth
0 siblings, 0 replies; 13+ messages in thread
From: bangerth @ 2003-03-14 21:19 UTC (permalink / raw)
To: drow, gcc-bugs, gcc-prs, nobody, tom.horsley
Synopsis: missing dwarf info for parent class
Responsible-Changed-From-To: unassigned->drow
Responsible-Changed-By: bangerth
Responsible-Changed-When: Fri Mar 14 21:19:17 2003
Responsible-Changed-Why:
Analyzed this PR
State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Fri Mar 14 21:19:17 2003
State-Changed-Why:
Daniel, what's the state of this? If debug generation is
really tied to the definition of the first virtual non-
abstract function, then I can't see how this could be
wrong: no program can be linked without having such a
definition, so at one point or other, a definition has to
be given, and then the executable also contains the debug
information. Unfortunately, my versions of readelf seems
to be too old to verify this myself.
W.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8095
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: debug/8095: missing dwarf info for parent class
@ 2002-10-01 5:06 Horsley Tom
0 siblings, 0 replies; 13+ messages in thread
From: Horsley Tom @ 2002-10-01 5:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR debug/8095; it has been noted by GNATS.
From: Horsley Tom <Tom.Horsley@ccur.com>
To: 'Daniel Jacobowitz' <drow@mvista.com>, Horsley Tom
<Tom.Horsley@ccur.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: RE: debug/8095: missing dwarf info for parent class
Date: Tue, 1 Oct 2002 08:02:44 -0400
> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Monday, September 30, 2002 4:38 PM
> To: tom.horsley@ccur.com
> Cc: gcc-gnats@gcc.gnu.org
> Subject: Re: debug/8095: missing dwarf info for parent class
>...
> Please provide a test case.
Weird. Every program I have exhibits this behavior. Here's
a random test program I picked this morning on my first try :-).
class Vtab1 {
public:
Vtab1();
Vtab1(int init_x);
virtual
~Vtab1();
virtual int
GetX();
private:
int x;
};
class Vtab2 {
public:
Vtab2();
Vtab2(int init_y);
virtual
~Vtab2();
virtual int
GetY();
private:
int y;
};
class Multiple1 : public Vtab1, public Vtab2 {
public:
Multiple1(int init_x, int init_y, int init_z);
virtual
~Multiple1();
virtual int
GetZ();
private:
int z;
};
class Derived1 : public Multiple1 {
public:
Derived1(int init_x, int init_y, int init_z);
virtual
~Derived1();
virtual int
GetX();
private:
int my_x;
};
Derived1::Derived1(int init_x, int init_y, int init_z)
: Multiple1(init_x, init_y, init_z) {
my_x = GetY();
}
Derived1::~Derived1() {
return;
}
int
Derived1::GetX() {
return my_x;
}
Using g++ 3.2 (Red Hat Linux Rawhide 3.2-1), if I compile
this as g++ -g -c d1.cpp and examine the dwarf in the d1.o file,
no symbols named "x","y", or "z" appear anywhere, and the
parent class info for Derived1 points to a DW_AT_declaration
for Multiple1, but there is no corresponding class definition
with a DW_AT_specification pointing to that Multiple1, so
no definition is available anywhere for the actual contents
of the parent classes, yet they are certainly used since
the type of the "this" pointer in the member functions
refers to them indirectly.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: debug/8095: missing dwarf info for parent class
@ 2002-09-30 13:46 Daniel Jacobowitz
0 siblings, 0 replies; 13+ messages in thread
From: Daniel Jacobowitz @ 2002-09-30 13:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR debug/8095; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: tom.horsley@ccur.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: debug/8095: missing dwarf info for parent class
Date: Mon, 30 Sep 2002 16:38:12 -0400
On Mon, Sep 30, 2002 at 12:45:44PM -0000, tom.horsley@ccur.com wrote:
>
> >Number: 8095
> >Category: debug
> >Synopsis: missing dwarf info for parent class
> >Confidential: no
> >Severity: serious
> >Priority: medium
> >Responsible: unassigned
> >State: open
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Mon Sep 30 05:46:05 PDT 2002
> >Closed-Date:
> >Last-Modified:
> >Originator: tom.horsley@ccur.com
> >Release: gcc 3.2
> >Organization:
> >Environment:
> redhat linux null beta
> >Description:
> I get the impression that g++ probably attempts to optimize the dwarf it generates to avoid generating masses of debug info for types that are not referenced in a compilation unit.
>
> That is all well and good, but it appears to go too far,
> leaving out parent classes even when it does generate the info for a derived class.
>
> If a type is "used", parent classes of that type should also be counted as "used".
> >How-To-Repeat:
> Any old C++ program with more than one level of class heirarchy will demonstrate this. Declare some instances of the most derived class, but never refer to the base class in the source code any place other than the derviced class declaration. The resulting dwarf will have no information about the members of the parent class.
>
> There is some chance you can find the parent definition in another compilation unit if it happens to be used there, but there are no guarantees you'll be able to find it anywhere. This makes symbolic debugging a bit difficult if you actually want to look at the base class members.
You need to be more precise. Not "any old C++ program" demonstrates
this. Here's a counterexample:
struct A {
int x;
};
struct B : public A {
int z;
};
B b;
<1><25>: Abbrev Number: 2 (DW_TAG_structure_type)
DW_AT_sibling : <7f>
DW_AT_name : A
DW_AT_byte_size : 4
DW_AT_decl_file : 1
DW_AT_decl_line : 1
<1><9d>: Abbrev Number: 2 (DW_TAG_structure_type)
DW_AT_sibling : <f7>
DW_AT_name : B
DW_AT_byte_size : 4
DW_AT_decl_file : 1
DW_AT_decl_line : 5
<2><a7>: Abbrev Number: 13 (DW_TAG_inheritance)
DW_AT_type : <25>
DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
DW_AT_accessibility: 1 (public)
Please provide a test case.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 13+ messages in thread
* debug/8095: missing dwarf info for parent class
@ 2002-09-30 5:46 tom.horsley
0 siblings, 0 replies; 13+ messages in thread
From: tom.horsley @ 2002-09-30 5:46 UTC (permalink / raw)
To: gcc-gnats
>Number: 8095
>Category: debug
>Synopsis: missing dwarf info for parent class
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Sep 30 05:46:05 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: tom.horsley@ccur.com
>Release: gcc 3.2
>Organization:
>Environment:
redhat linux null beta
>Description:
I get the impression that g++ probably attempts to optimize the dwarf it generates to avoid generating masses of debug info for types that are not referenced in a compilation unit.
That is all well and good, but it appears to go too far,
leaving out parent classes even when it does generate the info for a derived class.
If a type is "used", parent classes of that type should also be counted as "used".
>How-To-Repeat:
Any old C++ program with more than one level of class heirarchy will demonstrate this. Declare some instances of the most derived class, but never refer to the base class in the source code any place other than the derviced class declaration. The resulting dwarf will have no information about the members of the parent class.
There is some chance you can find the parent definition in another compilation unit if it happens to be used there, but there are no guarantees you'll be able to find it anywhere. This makes symbolic debugging a bit difficult if you actually want to look at the base class members.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2003-04-15 15:05 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-01 12:16 debug/8095: missing dwarf info for parent class Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2003-04-15 15:05 bangerth
2003-04-15 13:36 Daniel Jacobowitz
2003-03-17 14:26 Daniel Jacobowitz
2003-03-17 13:06 Horsley Tom
2003-03-14 22:06 Wolfgang Bangerth
2003-03-14 21:56 Wolfgang Bangerth
2003-03-14 21:56 Daniel Jacobowitz
2003-03-14 21:36 Daniel Jacobowitz
2003-03-14 21:19 bangerth
2002-10-01 5:06 Horsley Tom
2002-09-30 13:46 Daniel Jacobowitz
2002-09-30 5:46 tom.horsley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).