From: Daniel Jacobowitz <drow@mvista.com>
To: "H. J. Lu" <hjl@lucon.org>
Cc: David Carlton <carlton@kealia.com>, GDB <gdb@sources.redhat.com>
Subject: Re: gdb can't handle a DIE with both sibling and children
Date: Thu, 31 Jul 2003 20:02:00 -0000 [thread overview]
Message-ID: <20030731200215.GA17805@nevyn.them.org> (raw)
In-Reply-To: <20030731195640.GA16048@lucon.org>
On Thu, Jul 31, 2003 at 12:56:40PM -0700, H. J. Lu wrote:
> On Thu, Jul 31, 2003 at 12:36:15PM -0700, David Carlton wrote:
> > On Thu, 31 Jul 2003 14:20:49 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> >
> > > It seems quite clear that the code above is deliberately only
> > > visiting children of DW_TAG_enumeration_type and DW_TAG_namespace,
> > > since those are the only things whose children it needs to visit. I
> > > don't know why it was written that way, which does seem strange; I
> > > imagine it does a lot of useless recursing.
> >
> > It's not written in the clearest fashion. I have this cleaned up on
> > my branch to some extent, in a matter which, I hope, makes it clearer
> > that, normally, we always want to skip children (whether or not the
> > DIE happens to have a DW_AT_sibling attached to it): after all, most
> > of the information contained in children is information that we don't
> > need until a full symtab has been loaded. My rewrite then forks off
> > the special cases for which we actually do want to look at children
> > into their own special functions; maybe H.J. could add one for
> > subprograms that looks for entry point tags. (Assuming, of course,
> > that it really is important for the partial symbol table to know about
> > entry point tags, not just the full symbol table.)
> >
>
> I don't know for sure how DW_TAG_entry_point works. It seems to me
> that DW_TAG_entry_point should inherit DW_AT_accessibility and
> DW_AT_high_pc from its parent.
Certainly not high_pc. Its _bounds_ are the bounds of its parent; the
entry point is only specific PC that gets jumped to.
I don't know about DW_AT_accessibility. You'd have to ask someone who
knows more about Fortran than I do.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2003-07-31 20:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-31 18:13 H. J. Lu
2003-07-31 18:19 ` David Carlton
2003-07-31 18:20 ` Daniel Jacobowitz
2003-07-31 18:27 ` H. J. Lu
2003-07-31 18:47 ` Daniel Jacobowitz
2003-07-31 19:36 ` David Carlton
2003-07-31 19:56 ` H. J. Lu
2003-07-31 20:02 ` Daniel Jacobowitz [this message]
2003-07-31 20:22 ` H. J. Lu
2003-07-31 20:29 ` Daniel Jacobowitz
2003-07-31 20:58 ` H. J. Lu
2003-07-31 21:01 ` Daniel Jacobowitz
2003-07-31 20:29 ` David Carlton
2003-07-31 20:13 ` David Carlton
2003-07-31 20:37 Michael Elizabeth Chastain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030731200215.GA17805@nevyn.them.org \
--to=drow@mvista.com \
--cc=carlton@kealia.com \
--cc=gdb@sources.redhat.com \
--cc=hjl@lucon.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox