* [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit
@ 2004-08-06 21:10 David Lecomber
2004-09-14 20:00 ` Andrew Cagney
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: David Lecomber @ 2004-08-06 21:10 UTC (permalink / raw)
To: patches
[-- Attachment #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: 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 #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;
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit
2004-08-06 21:10 [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit David Lecomber
@ 2004-09-14 20:00 ` Andrew Cagney
2004-09-14 20:57 ` David Lecomber
2004-09-14 21:01 ` Michael Chastain
2004-09-14 21:04 ` Daniel Jacobowitz
2004-09-20 21:30 ` Jim Blandy
2 siblings, 2 replies; 7+ messages in thread
From: Andrew Cagney @ 2004-09-14 20:00 UTC (permalink / raw)
To: David Lecomber, Jim Blandy, Michael Elizabeth Chastain; +Cc: patches
[-- 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;
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit
2004-09-14 20:00 ` Andrew Cagney
@ 2004-09-14 20:57 ` David Lecomber
2004-09-14 21:01 ` Michael Chastain
1 sibling, 0 replies; 7+ messages in thread
From: David Lecomber @ 2004-09-14 20:57 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Jim Blandy, Michael Elizabeth Chastain, patches
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.
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit
2004-09-14 20:00 ` Andrew Cagney
2004-09-14 20:57 ` David Lecomber
@ 2004-09-14 21:01 ` Michael Chastain
1 sibling, 0 replies; 7+ messages in thread
From: Michael Chastain @ 2004-09-14 21:01 UTC (permalink / raw)
To: jimb, david, cagney; +Cc: gdb-patches
Andrew Cagney <cagney@gnu.org> wrote:
> 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 :-)
Okay, I'll bump it up my priority list.
Both of these patches were to address problems with non-gcc compilers.
So I really have to develop that part first. :-/
Michael
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit
2004-08-06 21:10 [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit David Lecomber
2004-09-14 20:00 ` Andrew Cagney
@ 2004-09-14 21:04 ` Daniel Jacobowitz
2004-09-14 21:21 ` David Lecomber
2004-09-20 21:30 ` Jim Blandy
2 siblings, 1 reply; 7+ messages in thread
From: Daniel Jacobowitz @ 2004-09-14 21:04 UTC (permalink / raw)
To: David Lecomber; +Cc: patches
On Fri, Aug 06, 2004 at 10:11:30PM +0100, David Lecomber wrote:
> 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.
Could you post the output of readelf -wil on this binary?
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit
2004-09-14 21:04 ` Daniel Jacobowitz
@ 2004-09-14 21:21 ` David Lecomber
0 siblings, 0 replies; 7+ messages in thread
From: David Lecomber @ 2004-09-14 21:21 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: patches
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
Hi Daniel,
It's attached,
D.
On Tue, 2004-09-14 at 22:04, Daniel Jacobowitz wrote:
> On Fri, Aug 06, 2004 at 10:11:30PM +0100, David Lecomber wrote:
> > 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.
>
> Could you post the output of readelf -wil on this binary?
[-- Attachment #2: nest.dwarf --]
[-- Type: text/plain, Size: 4646 bytes --]
The section .debug_info contains:
Compilation Unit @ 0:
Length: 239
Version: 2
Abbrev Offset: 0
Pointer Size: 4
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_comp_dir : /users/david
DW_AT_language : 8 (Fortran 90)
DW_AT_name : nest.f90
DW_AT_producer : Intel Fortran 8.0-4012
DW_AT_stmt_list : 0
<1><3e>: Abbrev Number: 2 (DW_TAG_base_type)
DW_AT_byte_size : 0
DW_AT_encoding : 5 (signed)
DW_AT_name : void
<1><46>: Abbrev Number: 3 (DW_TAG_subprogram)
DW_AT_decl_line : 1
DW_AT_decl_column : 8
DW_AT_decl_file : 1
DW_AT_accessibility: 1 (public)
DW_AT_calling_convention: 2 (program)
DW_AT_name : nest
DW_AT_type : <3e>
DW_AT_prototyped : 0
DW_AT_frame_base : 2 byte block: 75 48 (DW_OP_breg5: -56; )
DW_AT_high_pc : 0x8049dfe 134520318
DW_AT_low_pc : 0x8049db4 134520244
DW_AT_external : 1
<2><62>: Abbrev Number: 4 (DW_TAG_variable)
DW_AT_decl_line : 9
DW_AT_decl_column : 2
DW_AT_decl_file : 1
DW_AT_accessibility: 1 (public)
DW_AT_name : time
DW_AT_type : <d6>
DW_AT_location : 2 byte block: 91 8 (DW_OP_fbreg: 8; )
DW_AT_external : 0
DW_AT_start_scope : 0x8049df1 134520305
<2><78>: Abbrev Number: 4 (DW_TAG_variable)
DW_AT_decl_line : 4
DW_AT_decl_column : 16
DW_AT_decl_file : 1
DW_AT_accessibility: 1 (public)
DW_AT_name : i
DW_AT_type : <e1>
DW_AT_location : 2 byte block: 91 0 (DW_OP_fbreg: 0; )
DW_AT_external : 0
DW_AT_start_scope : 0x8049dd1 134520273
<2><8b>: Abbrev Number: 4 (DW_TAG_variable)
DW_AT_decl_line : 3
DW_AT_decl_column : 16
DW_AT_decl_file : 1
DW_AT_accessibility: 1 (public)
DW_AT_name : j
DW_AT_type : <e1>
DW_AT_location : 2 byte block: 91 4 (DW_OP_fbreg: 4; )
DW_AT_external : 0
DW_AT_start_scope : 0x8049dd1 134520273
<2><9e>: Abbrev Number: 5 (DW_TAG_subprogram)
DW_AT_decl_line : 13
DW_AT_decl_column : 14
DW_AT_decl_file : 1
DW_AT_accessibility: 1 (public)
DW_AT_name : second
DW_AT_type : <d6>
DW_AT_prototyped : 0
DW_AT_static_link : 3 byte block: 75 0 6
DW_AT_high_pc : 0x8049e12 134520338
DW_AT_low_pc : 0x8049dfe 134520318
DW_AT_external : 0
<3><bc>: Abbrev Number: 4 (DW_TAG_variable)
DW_AT_decl_line : 13
DW_AT_decl_column : 14
DW_AT_decl_file : 1
DW_AT_accessibility: 1 (public)
DW_AT_name : second
DW_AT_type : <d6>
DW_AT_location : 2 byte block: 75 5c (DW_OP_breg5: -36; )
DW_AT_external : 0
DW_AT_start_scope : 0x8049dfe 134520318
<1><d6>: Abbrev Number: 2 (DW_TAG_base_type)
DW_AT_byte_size : 4
DW_AT_encoding : 4 (float)
DW_AT_name : REAL(4)
<1><e1>: Abbrev Number: 2 (DW_TAG_base_type)
DW_AT_byte_size : 4
DW_AT_encoding : 5 (signed)
DW_AT_name : INTEGER(4)
Dump of debug contents of section .debug_line:
Length: 74
DWARF Version: 2
Prologue Length: 33
Minimum Instruction Length: 1
Initial value of 'is_stmt': 0
Line Base: -1
Line Range: 4
Opcode Base: 10
Opcodes:
Opcode 1 has 0 args
Opcode 2 has 1 args
Opcode 3 has 1 args
Opcode 4 has 1 args
Opcode 5 has 1 args
Opcode 6 has 0 args
Opcode 7 has 0 args
Opcode 8 has 0 args
Opcode 9 has 1 args
The Directory Table is empty.
The File Name Table:
Entry Dir Time Size Name
1 0 1095196755 219 nest.f90
Line Number Statements:
Extended opcode 2: set Address to 0x8049db4
Copy
Advance PC by 29 to 8049dd1
Advance Line by 4 to 5
Copy
Special opcode 30: advance Address by 7 to 0x8049dd8 and Line by 1 to 6
Special opcode 36: advance Address by 9 to 0x8049de1 and Line by -1 to 5
Special opcode 14: advance Address by 3 to 0x8049de4 and Line by 1 to 6
Advance PC by 5 to 8049de9
Advance Line by 3 to 9
Copy
Special opcode 59: advance Address by 14 to 0x8049df7 and Line by 2 to 11
Special opcode 31: advance Address by 7 to 0x8049dfe and Line by 2 to 13
Special opcode 26: advance Address by 6 to 0x8049e04 and Line by 1 to 14
Special opcode 38: advance Address by 9 to 0x8049e0d and Line by 1 to 15
Extended opcode 2: set Address to 0x8049e12
Extended opcode 1: End of Sequence
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit
2004-08-06 21:10 [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit David Lecomber
2004-09-14 20:00 ` Andrew Cagney
2004-09-14 21:04 ` Daniel Jacobowitz
@ 2004-09-20 21:30 ` Jim Blandy
2 siblings, 0 replies; 7+ messages in thread
From: Jim Blandy @ 2004-09-20 21:30 UTC (permalink / raw)
To: David Lecomber; +Cc: patches
David Lecomber <david@streamline-computing.com> writes:
> 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.
Thanks for posting the readelf -wil output Daniel requested. Could
you post (or somehow make available) a copy of the whole executable,
as produced by the Intel compiler? I would like to see how the Dwarf
reader is currently handling this information.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-09-20 21:30 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-08-06 21:10 [PATCH/RFA] buildsym.c: extend parent block bounds if child block exceed limit David Lecomber
2004-09-14 20:00 ` Andrew Cagney
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox