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;
next prev parent 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