From Mathieu.Lacage  Wed Nov  9 12:31:45 2005
From: Mathieu.Lacage (mathieu lacage)
Date: Wed Nov  9 12:31:45 2005
Subject: [Dwarf-discuss] basic_block semantics
Message-ID: <43725C8F.6070709@sophia.inria.fr>

hi,

I spent a while looking at this rarely-used piece of the dw2/3 standard, 
and I have to confess that I am a bit perplexed. I would be really happy 
if someone could help me figure out answers to the following questions

1) when DW_LNS_set_basic_block is executed, should I assume that the 
current value of the address register identifies the start of a basic 
block ? Or does the basic_block property applies upon the next change 
made to the address address ?

2) are the standard opcodes really supposed to have no effect on 
basic_block other than DW_LNS_set_basic_block and DW_LNS_copy ?

regards,
Mathieu


From Mathieu.Lacage  Wed Nov  9 13:01:11 2005
From: Mathieu.Lacage (mathieu lacage)
Date: Wed Nov  9 13:01:11 2005
Subject: [Dwarf-discuss] basic_block semantics
In-Reply-To: <43725C8F.6070709@sophia.inria.fr>
References: <43725C8F.6070709@sophia.inria.fr>
Message-ID: <4372637B.5050403@sophia.inria.fr>

hi,

As usual, I made a fool of myself. After much thinking, I figured out I 
had completely missed the basic idea behind the structure of the dwarf2 
line information. i.e., the fact that it is row-based and that the 
content of each column for each row is precisely defined.

And I will answer my own questions:

> 1) when DW_LNS_set_basic_block is executed, should I assume that the 
> current value of the address register identifies the start of a basic 
> block ? Or does the basic_block property applies upon the next change 
> made to the address address ?

It applies whenever a row is created from the registers.

> 2) are the standard opcodes really supposed to have no effect on 
> basic_block other than DW_LNS_set_basic_block and DW_LNS_copy ?


yes.

I suck,
Mathieu


From Chris.Quenelle  Wed Nov  9 16:16:39 2005
From: Chris.Quenelle (Chris Quenelle)
Date: Wed Nov  9 16:16:39 2005
Subject: [Dwarf-discuss] basic_block semantics
In-Reply-To: <4372637B.5050403@sophia.inria.fr>
References: <43725C8F.6070709@sophia.inria.fr>
	<4372637B.5050403@sophia.inria.fr>
Message-ID: <43729044.9030709@Sun.COM>


mathieu lacage wrote:
> As usual, I made a fool of myself. After much thinking, I figured out I 
> had completely missed the basic idea behind the structure of the dwarf2 
> line information. i.e., the fact that it is row-based and that the 
> content of each column for each row is precisely defined.


> I suck,
> Mathieu

If you had seen some of the emails in the working group related
to the line number table, you would not feel so bad. ;-)  My own
opinion is that the whole section needs to be rewritten.

--chris




From davea  Thu Nov 10 10:20:39 2005
From: davea (David Anderson)
Date: Thu Nov 10 10:20:39 2005
Subject: [Dwarf-discuss] basic_block semantics
References: <43725C8F.6070709@sophia.inria.fr>
	<4372637B.5050403@sophia.inria.fr>
Message-ID: <200511101817.jAAIHgV0367441@quasar.engr.sgi.com>


|mathieu lacage wrote:
|> As usual, I made a fool of myself. After much thinking, I figured out I 
|> had completely missed the basic idea behind the structure of the dwarf2 
|> line information. i.e., the fact that it is row-based and that the 
|> content of each column for each row is precisely defined.
|
|
|> I suck,
|> Mathieu

Chris.Quenelle writes
|If you had seen some of the emails in the working group related
|to the line number table, you would not feel so bad. ;-)  My own
|opinion is that the whole section needs to be rewritten.
|
|--chris

Another crucial observation (difficult to see this, I admit)
is that everything that creates a new table row resets
the begin-basic-block flag to 'false'.  Things that don't create
a new table row don't need to touch the flag (except the 'set'
operation).    

I sort of doubt much needs to be rewritten, but
I think mathieu lacage's comments suggest areas we could
clarify.  High level view issues, so to speak.

Or maybe we should encourage (or provide?) a new document
which brings these high level view things
into clear focus?    

David Anderson


From eager  Thu Nov 10 10:35:46 2005
From: eager (Michael Eager)
Date: Thu Nov 10 10:35:46 2005
Subject: [Dwarf-discuss] basic_block semantics
In-Reply-To: <200511101817.jAAIHgV0367441@quasar.engr.sgi.com>
References: <43725C8F.6070709@sophia.inria.fr>	<4372637B.5050403@sophia.inria.fr>
	<200511101817.jAAIHgV0367441@quasar.engr.sgi.com>
Message-ID: <437392EB.4000509@eagercon.com>

David Anderson wrote:
> |mathieu lacage wrote:
> |> As usual, I made a fool of myself. After much thinking, I figured out I 
> |> had completely missed the basic idea behind the structure of the dwarf2 
> |> line information. i.e., the fact that it is row-based and that the 
> |> content of each column for each row is precisely defined.

The DWARF document, like most standards, requires some close
reading.  It's possible to get off on the wrong foot and trip
yourself.

> Another crucial observation (difficult to see this, I admit)
> is that everything that creates a new table row resets
> the begin-basic-block flag to 'false'.  Things that don't create
> a new table row don't need to touch the flag (except the 'set'
> operation).    
> 
> I sort of doubt much needs to be rewritten, but
> I think mathieu lacage's comments suggest areas we could
> clarify.  High level view issues, so to speak.
> 
> Or maybe we should encourage (or provide?) a new document
> which brings these high level view things
> into clear focus?    

I think that this is something that would be appropriate
for a FAQ.

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


From davea  Thu Nov 10 11:29:59 2005
From: davea (David Anderson)
Date: Thu Nov 10 11:29:59 2005
Subject: [Dwarf-discuss] Suggestion of FAQ entries
Message-ID: <200511101928.jAAJSPRg366334@quasar.engr.sgi.com>


I'm asking (hereby) that new FAQ entries be created.

I'm posting this to the dwarf-discuss list so that
others can suggest better wording or correct any mistakes here.
I'm suggesting these because, for the first two, it
was brought up on a list as confusing folks, and
for the last (DW_FORM_ref_addr) at least one compiler
producer has (2005) used the bogus DWARF2 version for this.

A compiler producer has violated (in 2005)
the rule mentioned in the first FAQ entry proposed here.
(I'm not quite sure who the compiler producer is, I was given
compiled objects by someone I don't have explicit
permission to name here -- nobody in the DWARF list,
I believe.)


FAQ entry suggestions for Michael Eager to put on the
dwarf.freestandards.org FAQ:



------------------------------------------------------------
How many DW_TAG_compile_unit entries per Compilation Unit Header?

Each Compilation Unit Header should be followed by exactly one
DW_TAG_compile_unit or one DW_TAG_partial_unit, and the
children of the DW_TAG_compile_unit or DW_TAG_partial_unit
contain Debugging Information Entries for the unit.
A DW_TAG_compile_unit or one DW_TAG_partial_unit has
no sibling entries.



------------------------------------------------------------
Why doesn't the line table 'basic block' register have a reset operation?

It doesn't need one.  
The table  idea is based around creating row entries, conceptually
a row entry for every pc value in the executable text.
All the booleans in the line table, such
as is_stmt, basic_block, end_sequence, prologue_end, and 
epilogue_begin are reset by the creation of a new table_row
(see the individual opcodes that create table rows to see this).
Each row in the line table is defined by a sequence of one or more
line table opcodes and the opcodes precisely define
the value of every column of every row. 



------------------------------------------------------------
How big is a DW_FORM_ref_addr?

In DWARF3, DW_FORM_ref_addr is clearly defined as being 
an offset into the .debug_info section so the reference value
is the size of an offset. In DWARF2 DW_FORM_ref_addr
was (confusingly) defined as being the size of an address
on the target machine.  The DWARF2 definition never made
any sense and was a mistake in the DWARF2 specification:
the field DW_FORM_ref_addr defines is an offset, not an address.
Whether producing DWARF2 or DWARF3, please use the DWARF3
definition of DW_FORM_ref_addr.  


-------------------
David Anderson


From davea  Thu Nov 10 13:11:36 2005
From: davea (David Anderson)
Date: Thu Nov 10 13:11:36 2005
Subject: [Dwarf-discuss] Application of DWARF to kernel analysis
Message-ID: <200511102109.jAAL9v60370096@quasar.engr.sgi.com>


There is a new application of DWARF2 and I thought folks
on this list would be interested in hearing about it.
It recently moved to SourceForge where all can use it.

Cliff Wickman provided this summary at my request.

David Anderson,  davea at sgi dot com

-------------
                        Converting DWARF to DWARF

  Debugging the Linux kernel presents a need for thousands of kernel
  structure definitions.  But it is not possible to compile all the kernel
  include files at once.  So how do you collect all kernel structures?

  Someone in an SGI class once asked then-instructor Cliff Wickman 
  why we cannot compile the kernel and its modules with -g and then
  collect all their DWARF information into one file.  The answer was
  that we have no such tool.
  Hence the idea for dwarfextract.

  The program uses the DWARF consuming library routines to extract the
  types. It eliminates duplicates.  Then turns around and feeds them to
  the DWARF producing routines.  It creates a "kerntypes" file that looks
  like an ELF binary but contains nothing but DWARF information.

  This kerntypes file is used by the lcrash kernel debugger to
  cast memory images as any kernel type.

  The dwarfextract tool is part of the Linux Kernel Crash Dump (LKCD)
  project.  The project can be downloaded from sourceforge by:
    export CVSROOT=":pserver:anonymous at cvs.sourceforge.net:/cvsroot/lkcd"
    cvs login    # Press enter (eg no password) when prompted
    cvs -z3 co lkcd/7.X.X/lkcdutils
    cd lkcd/7.X.X/lkcdutils ; ./configure
-------------


From Keith.Walker  Fri Nov 11 02:02:58 2005
From: Keith.Walker (Keith Walker)
Date: Fri Nov 11 02:02:58 2005
Subject: [Dwarf-discuss] Suggestion of FAQ entries
Message-ID: <DD2D1CDF962D7346A5B0E5EE9CA36127063D9564@ZIPPY.Emea.Arm.com>

 
> ------------------------------------------------------------
> How many DW_TAG_compile_unit entries per Compilation Unit Header?
> 
> Each Compilation Unit Header should be followed by exactly 
> one DW_TAG_compile_unit or one DW_TAG_partial_unit, and the 
> children of the DW_TAG_compile_unit or DW_TAG_partial_unit 
> contain Debugging Information Entries for the unit.
> A DW_TAG_compile_unit or one DW_TAG_partial_unit has no 
> sibling entries.

I think that maybe it would be worth considering removing the
DW_AT_sibling entries from the DW_TAG_compile_unit and
DW_TAG_partial_unit entries in Figure 42 "Attributes by TAG value" in
the DWARF 3.0 Spec.

I think that the fact that the DW_AT_sibling entries are listed against
these tags can give the impression to someone reading the spec. that
compile units can have sibling entries (even if else where in the spec.
it states otherwise).

Keith


From eager  Fri Nov 11 09:40:07 2005
From: eager (Michael Eager)
Date: Fri Nov 11 09:40:07 2005
Subject: [Dwarf-discuss] Suggestion of FAQ entries
In-Reply-To: <DD2D1CDF962D7346A5B0E5EE9CA36127063D9564@ZIPPY.Emea.Arm.com>
References: <DD2D1CDF962D7346A5B0E5EE9CA36127063D9564@ZIPPY.Emea.Arm.com>
Message-ID: <4374D75C.6010403@eagercon.com>

Keith Walker wrote:
>  
> 
>>------------------------------------------------------------
>>How many DW_TAG_compile_unit entries per Compilation Unit Header?
>>
>>Each Compilation Unit Header should be followed by exactly 
>>one DW_TAG_compile_unit or one DW_TAG_partial_unit, and the 
>>children of the DW_TAG_compile_unit or DW_TAG_partial_unit 
>>contain Debugging Information Entries for the unit.
>>A DW_TAG_compile_unit or one DW_TAG_partial_unit has no 
>>sibling entries.
> 
> 
> I think that maybe it would be worth considering removing the
> DW_AT_sibling entries from the DW_TAG_compile_unit and
> DW_TAG_partial_unit entries in Figure 42 "Attributes by TAG value" in
> the DWARF 3.0 Spec.
> 
> I think that the fact that the DW_AT_sibling entries are listed against
> these tags can give the impression to someone reading the spec. that
> compile units can have sibling entries (even if else where in the spec.
> it states otherwise).

Proposals for changes in the DWARF specification should be made
using the DWARF website.

I believe that David was soliciting comments about FAQs.

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


From Chris.Quenelle  Mon Nov 14 19:37:13 2005
From: Chris.Quenelle (Chris Quenelle)
Date: Mon Nov 14 19:37:13 2005
Subject: [Dwarf-discuss] Application of DWARF to kernel analysis
In-Reply-To: <200511102109.jAAL9v60370096@quasar.engr.sgi.com>
References: <200511102109.jAAL9v60370096@quasar.engr.sgi.com>
Message-ID: <437956CA.3080702@Sun.COM>

Hi Dave,

This is exciting.  At Sun, the kernel group has invented their own
C-structure-describing debug format (called CTF) and they
go through the same process of merging CTF type information.
I've been trying to find time to implement something like
that for dwarf, and now it seems that someone else has the same
desire.

It looks like it's based on applying a bunch of patch diffs
to a specific version of the libdwarf source tar file.
Isn't that going to be an ongoing maintenance issue
for them?

--chris



David Anderson wrote:
> There is a new application of DWARF2 and I thought folks
> on this list would be interested in hearing about it.
> It recently moved to SourceForge where all can use it.
> 
> Cliff Wickman provided this summary at my request.
> 
> David Anderson,  davea at sgi dot com
> 
> -------------
>                         Converting DWARF to DWARF
> 
>   Debugging the Linux kernel presents a need for thousands of kernel
>   structure definitions.  But it is not possible to compile all the kernel
>   include files at once.  So how do you collect all kernel structures?
> 
>   Someone in an SGI class once asked then-instructor Cliff Wickman 
>   why we cannot compile the kernel and its modules with -g and then
>   collect all their DWARF information into one file.  The answer was
>   that we have no such tool.
>   Hence the idea for dwarfextract.
> 
>   The program uses the DWARF consuming library routines to extract the
>   types. It eliminates duplicates.  Then turns around and feeds them to
>   the DWARF producing routines.  It creates a "kerntypes" file that looks
>   like an ELF binary but contains nothing but DWARF information.
> 
>   This kerntypes file is used by the lcrash kernel debugger to
>   cast memory images as any kernel type.
> 
>   The dwarfextract tool is part of the Linux Kernel Crash Dump (LKCD)
>   project.  The project can be downloaded from sourceforge by:
>     export CVSROOT=":pserver:anonymous at cvs.sourceforge.net:/cvsroot/lkcd"
>     cvs login    # Press enter (eg no password) when prompted
>     cvs -z3 co lkcd/7.X.X/lkcdutils
>     cd lkcd/7.X.X/lkcdutils ; ./configure
> -------------
> _______________________________________________
> Dwarf-discuss mailing list
> Dwarf-discuss at freestandards.org
> http://mail.freestandards.org/mailman/listinfo/dwarf-discuss


From jeff.nelson  Mon Nov 14 22:18:52 2005
From: jeff.nelson (jeff nelson)
Date: Mon Nov 14 22:18:52 2005
Subject: [Dwarf-discuss] Application of DWARF to kernel analysis
In-Reply-To: <437956CA.3080702@Sun.COM>
References: <200511102109.jAAL9v60370096@quasar.engr.sgi.com>
	<437956CA.3080702@Sun.COM>
Message-ID: <1132035496.26092.98.camel@linux.site>

The linker on OpenVMS has this capability. When used with the /DSF
switch, the linker writes the debugger symbol table into a separate
file. The file has the same format as an executable program, but it
contains just debugging information. At the beginning of a debugging
session, the debugger first checks for the existence of a .DSF file.

-Jeff

On Mon, 2005-11-14 at 19:32 -0800, Chris Quenelle wrote:
> Hi Dave,
> 
> This is exciting.  At Sun, the kernel group has invented their own
> C-structure-describing debug format (called CTF) and they
> go through the same process of merging CTF type information.
> I've been trying to find time to implement something like
> that for dwarf, and now it seems that someone else has the same
> desire.
> 
> It looks like it's based on applying a bunch of patch diffs
> to a specific version of the libdwarf source tar file.
> Isn't that going to be an ongoing maintenance issue
> for them?
> 
> --chris
> 
> 
> 
> David Anderson wrote:
> > There is a new application of DWARF2 and I thought folks
> > on this list would be interested in hearing about it.
> > It recently moved to SourceForge where all can use it.
> > 
> > Cliff Wickman provided this summary at my request.
> > 
> > David Anderson,  davea at sgi dot com
> > 
> > -------------
> >                         Converting DWARF to DWARF
> > 
> >   Debugging the Linux kernel presents a need for thousands of kernel
> >   structure definitions.  But it is not possible to compile all the kernel
> >   include files at once.  So how do you collect all kernel structures?
> > 
> >   Someone in an SGI class once asked then-instructor Cliff Wickman 
> >   why we cannot compile the kernel and its modules with -g and then
> >   collect all their DWARF information into one file.  The answer was
> >   that we have no such tool.
> >   Hence the idea for dwarfextract.
> > 
> >   The program uses the DWARF consuming library routines to extract the
> >   types. It eliminates duplicates.  Then turns around and feeds them to
> >   the DWARF producing routines.  It creates a "kerntypes" file that looks
> >   like an ELF binary but contains nothing but DWARF information.
> > 
> >   This kerntypes file is used by the lcrash kernel debugger to
> >   cast memory images as any kernel type.
> > 
> >   The dwarfextract tool is part of the Linux Kernel Crash Dump (LKCD)
> >   project.  The project can be downloaded from sourceforge by:
> >     export CVSROOT=":pserver:anonymous at cvs.sourceforge.net:/cvsroot/lkcd"
> >     cvs login    # Press enter (eg no password) when prompted
> >     cvs -z3 co lkcd/7.X.X/lkcdutils
> >     cd lkcd/7.X.X/lkcdutils ; ./configure
> > -------------
> > _______________________________________________
> > Dwarf-discuss mailing list
> > Dwarf-discuss at freestandards.org
> > http://mail.freestandards.org/mailman/listinfo/dwarf-discuss
> _______________________________________________
> Dwarf-discuss mailing list
> Dwarf-discuss at freestandards.org
> http://mail.freestandards.org/mailman/listinfo/dwarf-discuss



