Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: David Lecomber <david@streamline-computing.com>
To: Andrew Cagney <cagney@gnu.org>
Cc: Jim Blandy <jimb@redhat.com>,
	Michael Elizabeth Chastain <mec.gnu@mindspring.com>,
	patches <gdb-patches@sources.redhat.com>
Subject: Re: [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit
Date: Tue, 14 Sep 2004 20:57:00 -0000	[thread overview]
Message-ID: <1095194858.5337.38.camel@localhost> (raw)
In-Reply-To: <41474D3D.4070809@gnu.org>

Hi Andrew,

This patch to buildsym hasn't gone in yet.

I've not had the pleasure of building a test-case for GDB yet; this
particular bug will only show up with the commercial F90 compilers -
it'll rely on Michael's changes to add 'optionalize' some compiler
specific tests -- I haven't been following where all this is now.

If Michael could do the first one, I would probably feel more
comfortable adding the extra test cases,

Cheers
David

On Tue, 2004-09-14 at 20:57, Andrew Cagney wrote:
> David,
> 
> Per an earlier discussion with myself and MichaelC (added to To:) its 
> really important that we get testcases for this and the other fortran 
> bugs in place.  I'm kind of begging here :-)
> 
> Once and only with the testcases in place do we have an assurance that 
> the next change (by someone else entirely) won't regress this existing 
> change.
> 
> Jim, I suspect everyone has assumed that this was a symtab patch :-)
> 
> Andrew
> 
> ______________________________________________________________________
> From: David Lecomber <david@streamline-computing.com>
> To: patches <gdb-patches@sources.redhat.com>
> Subject: [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit
> Date: Fri, 06 Aug 2004 22:11:30 +0100
> 
> All,
> 
> f90 compiled with nested subroutines using Intel's compiler is handled
> badly by GDB.  Line numbers are not found by backtrace.
> 
> Although GDB is capable of reading out all the dwarf2 line information
> inside this routine correctly, it can't look up an address to get a line
> number when inside a block.  The cause is that the containing function's
> block does not contain the contained function's address. 
> 
> 
> > (gdb) b nest.f90:14
> > Breakpoint 1 at 0x8049e04: file nest.f90, line 14.
> > (gdb) r
> > Starting program: /home/david/a.out
> > [Thread debugging using libthread_db enabled]
> > [New Thread 1024 (LWP 27093)]
> > [Switching to Thread 1024 (LWP 27093)]
> >  
> > Breakpoint 1, 0x08049e04 in nest_.second_ ()
> > (gdb) bt
> > #0  0x08049e04 in nest_.second_ ()
> > #1  0x08049dee in nest () at nest.f90:9
> > #2  0x08049da8 in main ()
> 
> where nest.f90 is attached and line 14 is in the middle of nested
> function second.
> 
> With the attached patch applied the result is:
> > (gdb) bt
> > #0  second () at nest.f90:14
> > #1  0x08049dee in nest () at nest.f90:9
> > #2  0x08049da8 in main ()
> 
> I'd like to propose the attached patch.  Presently if a child block extends 
> beyond the parent, the child is shrunk to the parent's bounds.  This reverses that.  
> I wouldn't like to guess the possible consequences of this change...
> 
> 
> 2004-08-06  David Lecomber  <dsl@sources.redhat.com>
> 
> 	* buildsym.c (finish_block): Extend parent block bounds when child 
> 	block exceeds current known bounds.
> 
> Can someone check this and approve/reject?
> 
> d.
> 


  reply	other threads:[~2004-09-14 20:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-06 21:10 David Lecomber
2004-09-14 20:00 ` Andrew Cagney
2004-09-14 20:57   ` David Lecomber [this message]
2004-09-14 21:01   ` Michael Chastain
2004-09-14 21:04 ` Daniel Jacobowitz
2004-09-14 21:21   ` David Lecomber
2004-09-20 21:30 ` Jim Blandy

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=1095194858.5337.38.camel@localhost \
    --to=david@streamline-computing.com \
    --cc=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@redhat.com \
    --cc=mec.gnu@mindspring.com \
    /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