This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: debug/8095: missing dwarf info for parent class
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: bangerth at dealii dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org,nobody at gcc dot gnu dot org, tom dot horsley at ccur dot com, gcc-gnats at gcc dot gnu dot org
- Date: Fri, 14 Mar 2003 16:33:41 -0500
- Subject: Re: debug/8095: missing dwarf info for parent class
- References: <20030314211918.19230.qmail@sources.redhat.com>
On Fri, Mar 14, 2003 at 09:19:18PM -0000, bangerth at dealii dot 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