gdb can't handle a DIE with both sibling and children

gdb can't handle a DIE with both sibling and children

[H. J. Lu]

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.

Re: gdb can't handle a DIE with both sibling and children

[David Carlton]

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

Re: gdb can't handle a DIE with both sibling and children

[Daniel Jacobowitz]

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

Re: gdb can't handle a DIE with both sibling and children

[H. J. Lu]

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

Re: gdb can't handle a DIE with both sibling and children

[Daniel Jacobowitz]

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

Re: gdb can't handle a DIE with both sibling and children

[David Carlton]

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

Re: gdb can't handle a DIE with both sibling and children

[H. J. Lu]

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

Re: gdb can't handle a DIE with both sibling and children

[Daniel Jacobowitz]

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

Re: gdb can't handle a DIE with both sibling and children

[David Carlton]

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

Re: gdb can't handle a DIE with both sibling and children

[H. J. Lu]

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.

Re: gdb can't handle a DIE with both sibling and children

[David Carlton]

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

Re: gdb can't handle a DIE with both sibling and children

[Daniel Jacobowitz]

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

Re: gdb can't handle a DIE with both sibling and children

[H. J. Lu]

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.

Re: gdb can't handle a DIE with both sibling and children

[Daniel Jacobowitz]

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

Re: gdb can't handle a DIE with both sibling and children

[Michael Elizabeth Chastain]

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