Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: David Lecomber <david@streamline-computing.com>,
	Jim Blandy <jimb@redhat.com>,
	Michael Elizabeth Chastain <mec.gnu@mindspring.com>
Cc: 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:00:00 -0000	[thread overview]
Message-ID: <41474D3D.4070809@gnu.org> (raw)
In-Reply-To: <1091826690.3932.33.camel@localhost>

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

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

[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 6082 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 1512 bytes --]

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.


[-- Attachment #2.1.2: nest.f90 --]
[-- Type: text/plain, Size: 219 bytes --]

PROGRAM Nest
 
        INTEGER j
        INTEGER i
        DO i=1, 100
        j = i
        END DO
 
  time = Second()
 
CONTAINS
 
REAL FUNCTION Second()
  Second = REAL(10)
END FUNCTION Second
 
 
END PROGRAM Nest
 

[-- Attachment #2.1.3: block.patch --]
[-- Type: text/x-patch, Size: 1056 bytes --]

Index: gdb/buildsym.c
===================================================================
RCS file: /cvs/src/src/gdb/buildsym.c,v
retrieving revision 1.39
diff -c -p -r1.39 buildsym.c
*** gdb/buildsym.c	7 Feb 2004 23:13:46 -0000	1.39
--- gdb/buildsym.c	28 Jul 2004 13:02:52 -0000
*************** finish_block (struct symbol *symbol, str
*** 421,429 ****
  			     paddr_nz (BLOCK_END (block)));
  		}
  	      if (BLOCK_START (pblock->block) < BLOCK_START (block))
! 		BLOCK_START (pblock->block) = BLOCK_START (block);
  	      if (BLOCK_END (pblock->block) > BLOCK_END (block))
! 		BLOCK_END (pblock->block) = BLOCK_END (block);
  	    }
  #endif
  	  BLOCK_SUPERBLOCK (pblock->block) = block;
--- 421,429 ----
  			     paddr_nz (BLOCK_END (block)));
  		}
  	      if (BLOCK_START (pblock->block) < BLOCK_START (block))
! 		BLOCK_START (block) = BLOCK_START (pblock->block); 
  	      if (BLOCK_END (pblock->block) > BLOCK_END (block))
! 		BLOCK_END (block) = BLOCK_END (pblock->block);
  	    }
  #endif
  	  BLOCK_SUPERBLOCK (pblock->block) = block;

  reply	other threads:[~2004-09-14 20:00 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 [this message]
2004-09-14 20:57   ` David Lecomber
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=41474D3D.4070809@gnu.org \
    --to=cagney@gnu.org \
    --cc=david@streamline-computing.com \
    --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