* gdb can't handle a DIE with both sibling and children
@ 2003-07-31 18:13 H. J. Lu
2003-07-31 18:19 ` David Carlton
2003-07-31 18:20 ` Daniel Jacobowitz
0 siblings, 2 replies; 15+ messages in thread
From: H. J. Lu @ 2003-07-31 18:13 UTC (permalink / raw)
To: GDB
It is entirely possible for a DIE with both sibling and children. But
scan_partial_symbols () has
/* If the die has a sibling, skip to the sibling. Do not skip
enumeration types, we want to record their enumerators. Do
not skip namespaces, we want to record symbols inside
them. */
if (pdi.sibling
&& pdi.tag != DW_TAG_enumeration_type
&& pdi.tag != DW_TAG_namespace)
{
info_ptr = pdi.sibling;
}
else if (pdi.has_children)
{
/* Die has children, but either the optional DW_AT_sibling
attribute is missing or we want to look at them. */
nesting_level++;
}
That is we can't handle a DIE with both sibling and children. How
should we fix that?
H.J.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
2003-07-31 18:13 gdb can't handle a DIE with both sibling and children H. J. Lu
@ 2003-07-31 18:19 ` David Carlton
2003-07-31 18:20 ` Daniel Jacobowitz
1 sibling, 0 replies; 15+ messages in thread
From: David Carlton @ 2003-07-31 18:19 UTC (permalink / raw)
To: H. J. Lu; +Cc: GDB
On Thu, 31 Jul 2003 11:13:55 -0700, "H. J. Lu" <hjl@lucon.org> said:
> It is entirely possible for a DIE with both sibling and children. But
> scan_partial_symbols () has
> /* If the die has a sibling, skip to the sibling. Do not skip
> enumeration types, we want to record their enumerators. Do
> not skip namespaces, we want to record symbols inside
> them. */
> if (pdi.sibling
> && pdi.tag != DW_TAG_enumeration_type
> && pdi.tag != DW_TAG_namespace)
> {
> info_ptr = pdi.sibling;
> }
> else if (pdi.has_children)
> {
> /* Die has children, but either the optional DW_AT_sibling
> attribute is missing or we want to look at them. */
> nesting_level++;
> }
The partial symbol table normally only contains info about top-level
symbols; so scan_partial_symbols rarely wants to look at children at
all. The full symbol table contains info about everything, though.
Is this causing you a problem in some specific situation?
David Carlton
carlton@kealia.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
2003-07-31 18:13 gdb can't handle a DIE with both sibling and children 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 19:36 ` David Carlton
1 sibling, 2 replies; 15+ messages in thread
From: Daniel Jacobowitz @ 2003-07-31 18:20 UTC (permalink / raw)
To: H. J. Lu; +Cc: GDB
On Thu, Jul 31, 2003 at 11:13:55AM -0700, H. J. Lu wrote:
> It is entirely possible for a DIE with both sibling and children. But
> scan_partial_symbols () has
>
> /* If the die has a sibling, skip to the sibling. Do not skip
> enumeration types, we want to record their enumerators. Do
> not skip namespaces, we want to record symbols inside
> them. */
> if (pdi.sibling
> && pdi.tag != DW_TAG_enumeration_type
> && pdi.tag != DW_TAG_namespace)
> {
> info_ptr = pdi.sibling;
> }
> else if (pdi.has_children)
> {
> /* Die has children, but either the optional DW_AT_sibling
> attribute is missing or we want to look at them. */
> nesting_level++;
> }
>
> That is we can't handle a DIE with both sibling and children. How
> should we fix that?
Why don't you be more specific? What problem is it causing, on what
input?
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. Probably because once we get to a nested die
with no siblings, this little algorithm has no way of finding the
parent except for scanning through all the children. This looks like a
bug.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
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
1 sibling, 1 reply; 15+ messages in thread
From: H. J. Lu @ 2003-07-31 18:27 UTC (permalink / raw)
To: GDB
On Thu, Jul 31, 2003 at 02:20:49PM -0400, Daniel Jacobowitz wrote:
>
> Why don't you be more specific? What problem is it causing, on what
> input?
>
I am trying to add support for DW_TAG_entry_point.
<1><8e>: Abbrev Number: 4 (DW_TAG_subprogram)
has both sibling and children. Since we skip to sibling, we miss the
children, which is
<2><c3>: Abbrev Number: 6 (DW_TAG_entry_point)
H.J.
----
The section .debug_info contains:
Compilation Unit @ 0:
Length: 304
Version: 2
Abbrev Offset: 0
Pointer Size: 4
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_comp_dir : /home/cmplr/usr2/mtokugaw
DW_AT_language : 8 (Fortran 90)
DW_AT_name : test.f
DW_AT_producer : EPC Fortran-95 Version F95 Intel:200200:131124
DW_AT_stmt_list : 0
<1><61>: Abbrev Number: 2 (DW_TAG_base_type)
DW_AT_byte_size : 0
DW_AT_encoding : 5 (signed)
DW_AT_name : void
<1><69>: Abbrev Number: 3 (DW_TAG_subprogram)
DW_AT_decl_line : 1
DW_AT_decl_column : 0
DW_AT_decl_file : 1
DW_AT_sibling : <8e>
DW_AT_accessibility: 1 (public)
DW_AT_calling_convention: 2 (program)
DW_AT_name : main.program
DW_AT_type : <61>
DW_AT_prototyped : 0
DW_AT_high_pc : 0x8049206 134517254
DW_AT_low_pc : 0x8049198 134517144
DW_AT_external : 1
<1><8e>: Abbrev Number: 4 (DW_TAG_subprogram)
DW_AT_decl_line : 6
DW_AT_decl_column : 0
DW_AT_decl_file : 1
DW_AT_sibling : <125>
DW_AT_accessibility: 1 (public)
DW_AT_name : wkinit
DW_AT_type : <61>
DW_AT_prototyped : 0
DW_AT_high_pc : 0x8049456 134517846
DW_AT_low_pc : 0x8049206 134517254
DW_AT_external : 1
<2><ac>: Abbrev Number: 5 (DW_TAG_formal_parameter)
DW_AT_decl_line : 31
DW_AT_decl_column : 0
DW_AT_decl_file : 1
DW_AT_type : <125>
DW_AT_variable_parameter: 1
DW_AT_name : wksize
DW_AT_location : 6 byte block: 3 8 a0 7 8 6 (DW_OP_addr: 807a008; DW_OP_deref)
<2><c3>: Abbrev Number: 6 (DW_TAG_entry_point)
DW_AT_decl_line : 20
DW_AT_decl_column : 0
DW_AT_decl_file : 1
DW_AT_sibling : <f2>
DW_AT_name : wkprnt
DW_AT_type : <61>
DW_AT_low_pc : 0x80492ac 134517420
<3><da>: Abbrev Number: 5 (DW_TAG_formal_parameter)
DW_AT_decl_line : 31
DW_AT_decl_column : 0
DW_AT_decl_file : 1
DW_AT_type : <125>
DW_AT_variable_parameter: 1
DW_AT_name : jprint
DW_AT_location : 6 byte block: 3 14 a0 7 8 6 (DW_OP_addr: 807a014; DW_OP_deref)
<2><f2>: Abbrev Number: 7 (DW_TAG_variable)
DW_AT_decl_line : 31
DW_AT_decl_column : 0
DW_AT_decl_file : 1
DW_AT_accessibility: 1 (public)
DW_AT_name : jpr
DW_AT_type : <125>
DW_AT_location : 5 byte block: 3 c a0 7 8 (DW_OP_addr: 807a00c)
DW_AT_external : 0
DW_AT_start_scope : 0x8049454 134517844
<2><10a>: Abbrev Number: 7 (DW_TAG_variable)
DW_AT_decl_line : 31
DW_AT_decl_column : 0
DW_AT_decl_file : 1
DW_AT_accessibility: 1 (public)
DW_AT_name : nsize
DW_AT_type : <125>
DW_AT_location : 5 byte block: 3 10 a0 7 8 (DW_OP_addr: 807a010)
DW_AT_external : 0
DW_AT_start_scope : 0x8049454 134517844
<1><125>: Abbrev Number: 2 (DW_TAG_base_type)
DW_AT_byte_size : 4
DW_AT_encoding : 5 (signed)
DW_AT_name : integer
Contents of the .debug_abbrev section:
Number TAG
1 DW_TAG_compile_unit [has children]
DW_AT_comp_dir DW_FORM_string
DW_AT_language DW_FORM_data1
DW_AT_name DW_FORM_string
DW_AT_producer DW_FORM_string
DW_AT_stmt_list DW_FORM_data4
2 DW_TAG_base_type [no children]
DW_AT_byte_size DW_FORM_data1
DW_AT_encoding DW_FORM_data1
DW_AT_name DW_FORM_string
3 DW_TAG_subprogram [no children]
DW_AT_decl_line DW_FORM_data1
DW_AT_decl_column DW_FORM_data1
DW_AT_decl_file DW_FORM_data1
DW_AT_sibling DW_FORM_ref4
DW_AT_accessibility DW_FORM_data1
DW_AT_calling_convention DW_FORM_data1
DW_AT_name DW_FORM_string
DW_AT_type DW_FORM_ref4
DW_AT_prototyped DW_FORM_flag
DW_AT_high_pc DW_FORM_addr
DW_AT_low_pc DW_FORM_addr
DW_AT_external DW_FORM_flag
4 DW_TAG_subprogram [has children]
DW_AT_decl_line DW_FORM_data1
DW_AT_decl_column DW_FORM_data1
DW_AT_decl_file DW_FORM_data1
DW_AT_sibling DW_FORM_ref4
DW_AT_accessibility DW_FORM_data1
DW_AT_name DW_FORM_string
DW_AT_type DW_FORM_ref4
DW_AT_prototyped DW_FORM_flag
DW_AT_high_pc DW_FORM_addr
DW_AT_low_pc DW_FORM_addr
DW_AT_external DW_FORM_flag
5 DW_TAG_formal_parameter [no children]
DW_AT_decl_line DW_FORM_data1
DW_AT_decl_column DW_FORM_data1
DW_AT_decl_file DW_FORM_data1
DW_AT_type DW_FORM_ref4
DW_AT_variable_parameter DW_FORM_flag
DW_AT_name DW_FORM_string
DW_AT_location DW_FORM_block1
6 DW_TAG_entry_point [has children]
DW_AT_decl_line DW_FORM_data1
DW_AT_decl_column DW_FORM_data1
DW_AT_decl_file DW_FORM_data1
DW_AT_sibling DW_FORM_ref4
DW_AT_name DW_FORM_string
DW_AT_type DW_FORM_ref4
DW_AT_low_pc DW_FORM_addr
7 DW_TAG_variable [no children]
DW_AT_decl_line DW_FORM_data1
DW_AT_decl_column DW_FORM_data1
DW_AT_decl_file DW_FORM_data1
DW_AT_accessibility DW_FORM_data1
DW_AT_name DW_FORM_string
DW_AT_type DW_FORM_ref4
DW_AT_location DW_FORM_block1
DW_AT_external DW_FORM_flag
DW_AT_start_scope DW_FORM_addr
Dump of debug contents of section .debug_line:
Length: 94
DWARF Version: 2
Prologue Length: 31
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 1059586658 583 test.f
Line Number Statements:
Extended opcode 2: set Address to 0x8049198
Copy
Special opcode 158: advance Address by 39 to 0x80491bf and Line by 1 to 2
Special opcode 82: advance Address by 20 to 0x80491d3 and Line by 1 to 3
Special opcode 82: advance Address by 20 to 0x80491e7 and Line by 1 to 4
Special opcode 127: advance Address by 31 to 0x8049206 and Line by 2 to 6
Advance PC by 11 to 8049211
Advance Line by 7 to 13
Copy
Special opcode 51: advance Address by 12 to 0x804921d and Line by 2 to 15
Advance PC by 126 to 804929b
Advance Line by 2 to 17
Copy
Advance PC by 17 to 80492ac
Advance Line by 3 to 20
Copy
Special opcode 46: advance Address by 11 to 0x80492b7 and Line by 1 to 21
Advance PC by 124 to 8049333
Advance Line by 1 to 22
Copy
Advance PC by 126 to 80493b1
Advance Line by 1 to 23
Copy
Special opcode 50: advance Address by 12 to 0x80493bd and Line by 1 to 24
Special opcode 63: advance Address by 15 to 0x80493cc and Line by 2 to 26
Special opcode 51: advance Address by 12 to 0x80493d8 and Line by 2 to 28
Advance PC by 124 to 8049454
Advance Line by 3 to 31
Copy
Extended opcode 2: set Address to 0x8049456
Extended opcode 1: End of Sequence
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
2003-07-31 18:27 ` H. J. Lu
@ 2003-07-31 18:47 ` Daniel Jacobowitz
0 siblings, 0 replies; 15+ messages in thread
From: Daniel Jacobowitz @ 2003-07-31 18:47 UTC (permalink / raw)
To: H. J. Lu; +Cc: GDB
On Thu, Jul 31, 2003 at 11:27:12AM -0700, H. J. Lu wrote:
> On Thu, Jul 31, 2003 at 02:20:49PM -0400, Daniel Jacobowitz wrote:
> >
> > Why don't you be more specific? What problem is it causing, on what
> > input?
> >
>
> I am trying to add support for DW_TAG_entry_point.
>
> <1><8e>: Abbrev Number: 4 (DW_TAG_subprogram)
>
> has both sibling and children. Since we skip to sibling, we miss the
> children, which is
>
> <2><c3>: Abbrev Number: 6 (DW_TAG_entry_point)
In that case, you're changing the invariants of that function. You'll
have to find a new algorithm for it.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
2003-07-31 18:20 ` Daniel Jacobowitz
2003-07-31 18:27 ` H. J. Lu
@ 2003-07-31 19:36 ` David Carlton
2003-07-31 19:56 ` H. J. Lu
1 sibling, 1 reply; 15+ messages in thread
From: David Carlton @ 2003-07-31 19:36 UTC (permalink / raw)
To: H. J. Lu; +Cc: GDB
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 think, actually, that some or all of that cleanup is in my current
patch waiting for approval. I really should get back to merging my
branch in; I've been too busy with other work to be really active
in that effort.
David Carlton
carlton@kealia.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
2003-07-31 19:36 ` David Carlton
@ 2003-07-31 19:56 ` H. J. Lu
2003-07-31 20:02 ` Daniel Jacobowitz
2003-07-31 20:13 ` David Carlton
0 siblings, 2 replies; 15+ messages in thread
From: H. J. Lu @ 2003-07-31 19:56 UTC (permalink / raw)
To: David Carlton; +Cc: GDB
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.
H.J.
----
<1><8e>: Abbrev Number: 4 (DW_TAG_subprogram)
DW_AT_decl_line : 6
DW_AT_decl_column : 0
DW_AT_decl_file : 1
DW_AT_sibling : <125>
DW_AT_accessibility: 1 (public)
DW_AT_name : wkinit
DW_AT_type : <61>
DW_AT_prototyped : 0
DW_AT_high_pc : 0x8049456 134517846
DW_AT_low_pc : 0x8049206 134517254
DW_AT_external : 1
<2><c3>: Abbrev Number: 6 (DW_TAG_entry_point)
DW_AT_decl_line : 20
DW_AT_decl_column : 0
DW_AT_decl_file : 1
DW_AT_sibling : <f2>
DW_AT_name : wkprnt
DW_AT_type : <61>
DW_AT_low_pc : 0x80492ac 134517420
---
implicit none
call wkinit(10)
call wkprnt(5)
end
subroutine wkinit(wksize)
implicit none
integer wksize, nsize
integer jpr
integer jprint
save jpr
jpr = wksize
print *, 'On entry, wksize = ',wksize
nsize = wksize
return
entry wkprnt(jprint)
print *, 'On entry, jpr = ',jpr
print *, 'On entry, jprint = ',jprint
if (jprint.eq.2) then
jpr = 1-jpr
else
jpr = jprint
endif
print *, 'jpr = ',jpr
return
end
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
2003-07-31 19:56 ` H. J. Lu
@ 2003-07-31 20:02 ` Daniel Jacobowitz
2003-07-31 20:22 ` H. J. Lu
2003-07-31 20:13 ` David Carlton
1 sibling, 1 reply; 15+ messages in thread
From: Daniel Jacobowitz @ 2003-07-31 20:02 UTC (permalink / raw)
To: H. J. Lu; +Cc: David Carlton, GDB
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
2003-07-31 19:56 ` H. J. Lu
2003-07-31 20:02 ` Daniel Jacobowitz
@ 2003-07-31 20:13 ` David Carlton
1 sibling, 0 replies; 15+ messages in thread
From: David Carlton @ 2003-07-31 20:13 UTC (permalink / raw)
To: H. J. Lu; +Cc: GDB
On Thu, 31 Jul 2003 12:56:40 -0700, "H. J. Lu" <hjl@lucon.org> said:
> 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.
I'm a little confused both from reading the DWARF 3 standard and from
reading your code below; the standard doesn't really talk about why a
DW_TAG_entry_point would or wouldn't be contained in a
DW_TAG_subroutine, and I don't know any Fortran to help me figure this
out.
So: what does it mean for a subroutine to have another entry point? I
see that that entry point has a name; is that name visible to other
compilation units, or only to the compilation unit in question? If
it's only visible to the compilation unit in question, then the
partial symtab probably doesn't have to know about it at all. If it's
visible outside the compilation unit (and if the compiler really is
correct in putting DW_TAG_entry_points as children of
DW_TAG_subroutines), then the partial symtab probably does have to
know about it. In that case, you might want to look at what
<http://sources.redhat.com/ml/gdb-patches/2003-06/msg00838.html> does
to scan_partial_symbols; you could add an add_partial_subroutine
function to it that looks for entry point tags within subroutines.
David Carlton
carlton@kealia.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
2003-07-31 20:02 ` Daniel Jacobowitz
@ 2003-07-31 20:22 ` H. J. Lu
2003-07-31 20:29 ` Daniel Jacobowitz
2003-07-31 20:29 ` David Carlton
0 siblings, 2 replies; 15+ messages in thread
From: H. J. Lu @ 2003-07-31 20:22 UTC (permalink / raw)
To: David Carlton, GDB
On Thu, Jul 31, 2003 at 04:02:15PM -0400, Daniel Jacobowitz wrote:
> >
> > 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.
The entry point is DW_AT_low_pc. From what I can see, its DW_AT_high_pc
should be the same as its parent. See
http://www-sld.slac.stanford.edu/HELP/FORTRAN/STATEMENTS/ENTRY
H.J.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
2003-07-31 20:22 ` H. J. Lu
2003-07-31 20:29 ` Daniel Jacobowitz
@ 2003-07-31 20:29 ` David Carlton
1 sibling, 0 replies; 15+ messages in thread
From: David Carlton @ 2003-07-31 20:29 UTC (permalink / raw)
To: H. J. Lu; +Cc: GDB
On Thu, 31 Jul 2003 13:22:29 -0700, "H. J. Lu" <hjl@lucon.org> said:
> See
> http://www-sld.slac.stanford.edu/HELP/FORTRAN/STATEMENTS/ENTRY
Blech. Fortran is gross. Yes, you'll have to modify
scan_partial_symbols. I'm just glad that entries can't contain
DW_AT_specification; then we'd really be screwed.
David Carlton
carlton@kealia.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
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 20:29 ` David Carlton
1 sibling, 1 reply; 15+ messages in thread
From: Daniel Jacobowitz @ 2003-07-31 20:29 UTC (permalink / raw)
To: H. J. Lu; +Cc: David Carlton, GDB
On Thu, Jul 31, 2003 at 01:22:29PM -0700, H. J. Lu wrote:
> On Thu, Jul 31, 2003 at 04:02:15PM -0400, Daniel Jacobowitz wrote:
> > >
> > > 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.
>
> The entry point is DW_AT_low_pc. From what I can see, its DW_AT_high_pc
> should be the same as its parent. See
>
> http://www-sld.slac.stanford.edu/HELP/FORTRAN/STATEMENTS/ENTRY
Think about this for a moment.
DW_AT_low_pc represents a PC - an entry point.
DW_AT_low_pc + DW_AT_high_pc represents a range - a whole subroutine.
The bounds of the entry point are the bounds of the entire function, or
none at all. Inheriting DW_AT_high_pc makes no sense. In Fortran,
they represent a low_pc->high_pc range, but there are a number of other
useful meanings for it.
Besides, what would you do if a function had DW_AT_ranges?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
2003-07-31 20:29 ` Daniel Jacobowitz
@ 2003-07-31 20:58 ` H. J. Lu
2003-07-31 21:01 ` Daniel Jacobowitz
0 siblings, 1 reply; 15+ messages in thread
From: H. J. Lu @ 2003-07-31 20:58 UTC (permalink / raw)
To: David Carlton, GDB
On Thu, Jul 31, 2003 at 04:29:35PM -0400, Daniel Jacobowitz wrote:
> On Thu, Jul 31, 2003 at 01:22:29PM -0700, H. J. Lu wrote:
> > On Thu, Jul 31, 2003 at 04:02:15PM -0400, Daniel Jacobowitz wrote:
> > > >
> > > > 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.
> >
> > The entry point is DW_AT_low_pc. From what I can see, its DW_AT_high_pc
> > should be the same as its parent. See
> >
> > http://www-sld.slac.stanford.edu/HELP/FORTRAN/STATEMENTS/ENTRY
>
> Think about this for a moment.
>
> DW_AT_low_pc represents a PC - an entry point.
>
> DW_AT_low_pc + DW_AT_high_pc represents a range - a whole subroutine.
>
> The bounds of the entry point are the bounds of the entire function, or
> none at all. Inheriting DW_AT_high_pc makes no sense. In Fortran,
> they represent a low_pc->high_pc range, but there are a number of other
> useful meanings for it.
>
What should high_pc of an entry point be if it is not specified?
H.J.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
2003-07-31 20:58 ` H. J. Lu
@ 2003-07-31 21:01 ` Daniel Jacobowitz
0 siblings, 0 replies; 15+ messages in thread
From: Daniel Jacobowitz @ 2003-07-31 21:01 UTC (permalink / raw)
To: GDB
On Thu, Jul 31, 2003 at 01:58:36PM -0700, H. J. Lu wrote:
> On Thu, Jul 31, 2003 at 04:29:35PM -0400, Daniel Jacobowitz wrote:
> > On Thu, Jul 31, 2003 at 01:22:29PM -0700, H. J. Lu wrote:
> > > On Thu, Jul 31, 2003 at 04:02:15PM -0400, Daniel Jacobowitz wrote:
> > > > >
> > > > > 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.
> > >
> > > The entry point is DW_AT_low_pc. From what I can see, its DW_AT_high_pc
> > > should be the same as its parent. See
> > >
> > > http://www-sld.slac.stanford.edu/HELP/FORTRAN/STATEMENTS/ENTRY
> >
> > Think about this for a moment.
> >
> > DW_AT_low_pc represents a PC - an entry point.
> >
> > DW_AT_low_pc + DW_AT_high_pc represents a range - a whole subroutine.
> >
> > The bounds of the entry point are the bounds of the entire function, or
> > none at all. Inheriting DW_AT_high_pc makes no sense. In Fortran,
> > they represent a low_pc->high_pc range, but there are a number of other
> > useful meanings for it.
> >
>
> What should high_pc of an entry point be if it is not specified?
The bounds of the entry point are the bounds of the containing
function.
The entry point of the entry point is its DW_AT_low_pc.
They're not related...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: gdb can't handle a DIE with both sibling and children
@ 2003-07-31 20:37 Michael Elizabeth Chastain
0 siblings, 0 replies; 15+ messages in thread
From: Michael Elizabeth Chastain @ 2003-07-31 20:37 UTC (permalink / raw)
To: carlton, hjl; +Cc: gdb
David Carlton asks:
> So: what does it mean for a subroutine to have another entry point? I
> see that that entry point has a name; is that name visible to other
> compilation units, or only to the compilation unit in question?
The former. The entry point is globally visible, just like the
main function name.
I never actually wrote an ENTRY statement, but here's a classic
FORTRAN example, where the body of "sine" and "cosine" would be
the same:
double function sine (angle)
double angle
goto 10
entry cosine (angle)
angle = (3.14159265358979/4) - angle
goto 10
10 ... calculate the sine here ...
return
end
Of course, one could have implemented this as:
double entry cosine (angle)
return sine (3.14159265358979/4 - angle)
end
But that's a waste of CPU time, back when the CPU was running
at 0.1 MHz.
For a modern example, it would be possible to implement those
pesky in-charge/not-in-charge constructors with one body of code
with 2 or 3 entry points.
> If it's only visible to the compilation unit in question, then the
> partial symtab probably doesn't have to know about it at all. If it's
> visible outside the compilation unit (and if the compiler really is
> correct in putting DW_TAG_entry_points as children of
> DW_TAG_subroutines), then the partial symtab probably does have to know
> about it.
The main name and the entry names have the same visibility.
To the caller, 'sine' and 'cosine' are peers.
Michael C
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-07-31 21:01 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-31 18:13 gdb can't handle a DIE with both sibling and children 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).