Re: [Dwarf-discuss] OTHER or arguably ENHANCEMENT: Logo

[Michael Eager via Dwarf-discuss]

On 3/22/23 13:00, Ron Brender via Dwarf-discuss wrote:
FWIW, the "master" in the DWARF .git distro is an .eps file not 
.png--not that that really matters. I don't know
where it came from other than Michael gave it to me to use. The .eps 
does contain some Copyright lines, namely

% Copyright (c)1992-98 Corel Corporation
% All rights reserved.     v8.0 r0.15
I suspect it came out of some WordPerfect sample graphics selection 
which he tweaked for DWARF use--my speculation.


I designed and created the logo using Corel Draw.  The image of the 
little Viking came from a multi-CD digital clip art collection that I 
purchased long ago.  (The image reminded me of Grieg's "In the Hall of 
the Mountain King".)


The original is a .cdr file, which is scalable and can be used to 
generate graphics in a variety of resolutions and formats, including 
PNGs optimized for a web page, or EPS files for printing.


The copyright notice is for Corel's PostScript code in the EPS file, not 
for the entire graphic.


--
Michael Eager
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-Discuss] Unnamed zero sized bit-fields (Re: Corner-cases with bitfields)

[Michael Eager via Dwarf-Discuss]

On 5/10/22 04:10, Pedro Alves via Dwarf-Discuss wrote:

On 2022-05-06 18:11, Lancelot SIX via Dwarf-Discuss wrote:


2 - Unnamed zero sized bitfield

Another case we met is related to unnamed fields with a size of 0 bits.
Such field is defined in the c++ standard as (in 9.6 Bit-Fields):

  > As a special case, an unnamed bit-field with a width of zero
  > specifies alignment of the next bit-field at an allocation unit
  > boundary

If we now consider an extended version of our previous example:

  struct Foo
  {
char a : 8;
char : 0;
char b : 8,
  };

Neither GCC nor Clang give any information about the unnamed bitfield.
As for the previous case, the presence of such field impacts how
arguments are passed during function calls on our target, leaving the
debugger unable to properly decide how to handle such cases.

As for the previous case, both compilers can properly describe Foo's
memory layout using DW_AT_bit_offset.

It seems that such 0-sized field also has impact on ABI on other targets
such as armv7hl and aarch64 as discussed in [2].  Should the DWARF
specification give some guidance on how to handle such situation?

All thoughts on those cases are welcome.


In DWARF 5, we have:

"5.7.6
  Data Member Entries
A data member (as opposed to a member function) is represented by a
debugging information entry with the tag DW_TAG_member. The member
entry for a named member has a DW_AT_name attribute whose value is a
null-terminated string containing the member name. If the member entry
describes an anonymous union, the name attribute is omitted or the value of the
attribute consists of a single zero byte."

I didn't find anything that would prevent a producer from emitting an
unnamed bit-field member.  Ignoring the 0-size special case for the moment,
neither GCC nor Clang emit the unnamed bit-field in this case either:

 struct Foo
 {
   char a : 8;
   char : 8;
   char b : 8;
 };

I suppose you could call it QoI to emit an unnamed field for this unnamed 
bit-field,
in the same vein of what I mentioned earlier about making it possible for the 
debugger to
reconstruct the original type (a debugger could infer the size of the unnamed 
bit-field
from the gap, but not its declared type).  I didn't find wording in the spec 
that
would prevent it.


Nothing in DWARF would seem to prohibit generating a unnamed field, nor
would anything require it.  It's QoI; with it a debugger can print an
field without a name, without you cannot.  (It's possible that a 
debugger might not expect a zero-size field, but that, too, is QoI.)



 From that angle, unnamed zero-sized bit-fields could also be emitted, ISTM 
that it's
technically possible to describe it with current DWARF, though, 
consumer-implementation-wise,
a consumer may need to be able to distinguish "no DW_AT_bit_size present" vs
"DW_AT_bit_size present and value is 0".  Anyone see an issue with making that 
distinction
DWARF-spec wise?  Could that result in ambiguities somewhere?  I don't think 
that GDB makes
such a distinction currently, I think internally "bit size == 0" means not a 
bit field,
but that would be changed, of course, it's implementation detail.


A proposal for DWARF to require DW_AT_bit_size for all bit fields would
address this.


For some reason (maybe because of the weird "single zero byte" special case?), 
the
wording above from 5.7.6 describes what to do with anonymous unions, kind of 
giving
the impression that it could also specify what is expected with other unnamed 
fields
such as unnamed bit-fields.


That line might be tweaked to apply to all unnamed entities.


OTOH, we have "D.2.8 C/C++ Bit-Field Examples", where the spec says "Bit fields 
in C and C++
typically require the use of the DW_AT_data_bit_offset and DW_AT_bit_size 
attributes.".
It then goes on to give examples of big- and little-endian machines.  Maybe 
this chapter would
be the spot where the spec would give the example of what to do with unnamed 
bit-fields
of 0 size, as _it is_ a special case described in the C++ language spec, i.e., 
has meaning
at the language level that is lost otherwise, and the D.2.8 chapter in the 
DWARF spec is
specifically about C/C++.


The Appendices are not normative parts of the standard.  They only offer
suggestions on how to represent various situations.  Changes in how
unnamed bit fields should be described would be in the body of the 
standard.  (And the example could be extended.)



Or this is yet another case that people would prefer to leave things as is 
DWARF-spec-wise
and we should go file bug reports with GCC and Clang?


Submit an issue to DWARF to have the standard clarified/enhanced and
file a bug report with GCC & Clang.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields

[Michael Eager via Dwarf-Discuss]

On 5/10/22 02:15, Pedro Alves via Dwarf-Discuss wrote:

  But still, at the language level, the types ARE different.  And DWARF is
also about language source to machine code mapping.  C/C++ don't let you take 
the
address of a bitfield, for example, so it's possible type expressions in the
debugger that behave differently depending on what the DWARF described.


In a previous email in this thread, I mentioned that I thought "char a;"
and "char a:8" in a struct were equivalent.  I forgot about the
restriction on using the address operator, mentioned in ISO C Sect.
6.5.3.2 (at least, in the old copy I have).  They are not equivalent.
Thanks for reminding me.


So in my view, you'd want a producer to always indicate that the field
is a bitfield somehow, even if the memory layout wouldn't change, i.e.,
regardless of ABI.

Maybe we can convince Clang folks of the same as GCC, that certainly sounds 
simpler,
but I figured that maybe there would be agreement that the spec itself should 
be tweaked
in this direction, if every producer would come to the same conclusion.


It's better to propose a change to the DWARF Standard.

You can submit a proposal on the Public Comment page:
https://dwarfstd.org/Comment.php.  Describe the issue briefly and, if
possible, please specify the change to the wording of the DWARF
Standard that would think appropriate.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields

[Michael Eager via Dwarf-Discuss]

On 5/9/22 16:00, Todd Allen via Dwarf-Discuss wrote:

I suppose, if you didn't want to submit an issue, another solution would be to
require the necessary tags & attributes in the ABI itself.  We already expect
ABI documents to provide things like register values, CFI initial values, and
some more esoteric stuff (augmentations, non-standard endianity & isa).  An ABI
that required descriptions in ABI-specific situations like these two seems
reasonable to me.  And it places no burden on compilers for other ABI's.


This creates the situation where there are two definitions for a DWARF 
attribute, one in an ABI and a different one in the DWARF Spec.  We want 
to avoid situations where one producer says "I'm following DWARF" and 
another "I'm following the ABI".  That makes interoperability difficult.


The information you mention in an ABI is not in the DWARF Spec.


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] EXTERNAL: Corner-cases with bitfields

[Michael Eager via Dwarf-Discuss]

On 5/9/22 13:18, Pedro Alves via Dwarf-Discuss wrote:

An issue here is that DWARF does say this, in (DWARF 5, 5.7.6 Data Member 
Entries, page 119):

  "If the size of a data member is not the same as the size of the type given 
for the
   
^
  data member, the data member has either a DW_AT_byte_size or a
  ^^^
  DW_AT_bit_size attribute whose integer constant value (see Section 2.19 on
  page 55) is the amount of storage needed to hold the value of the data 
member."

Note the part I underlined.  In Lancelot's case, the size of the data member
IS the same as the size of the type given for the data member.  So Clang could 
well pedantically
claim that they _are_ following the spec.  Shouldn't the spec be clarified here?

This then raises the question of whether a debugger can assume that the 
presence of a DW_AT_bit_size
attribute indicates that the field is a bit field at the C/C++ source level.  
GDB is assuming that
today, as there's really no other way to tell, but I don't think the spec 
explicitly says so.


DWARF tries to avoid having one piece of information with a clear 
description imply or suggest something else, with perhaps different 
implications for different people.


It seems to me that other languages (Ada?) have variables which do not 
fill the data type, so it would be reasonable for them to have a 
DW_AT_bit_size which is different from the data type size, yet not be a 
bit field.


As currently described, DW_AT_bit_size only describes the size of the 
data, nothing more, and only when that cannot be determined from the 
size of the base type.  If you want to change the definition to say that 
it has an additional meaning (describing a bit field with a certain 
size), submit an issue.  Alternately, Todd suggested a new flag to 
identify a bit field.


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Corner-cases with bitfields

[Michael Eager via Dwarf-Discuss]

On 5/6/22 10:11, Lancelot SIX via Dwarf-Discuss wrote:

Dear all,

During our work on debugging support of compute workloads on AMDGPU[1],
we (at AMD) have been seeing two cases regarding description of
bitfields in DWARF for which we do not find definitive answers in the
DWARF documentation.  For those cases, when experiencing with usual CPU
targets we observe different behaviors on different toolchains.  As a
consequence, we would like to discuss those points here to gather
feedbacks.  If deemed necessary, we will submit a formal clarification
issue to the dwarf committee.

Both of the cases we present below impact how arguments are passed
during function calls in the ABI for at least our target (AMDGPU).
However, the debug information available to the debugger does not give
enough information to decide how to handle the type and the spec does
not really say what debug information should be generated to properly
describe those cases.  Also note that in both case, the DWARF
information we have is sufficient to describe the memory layout of the
types.

1 - Bitfield member with a size matching its underlying type:

The first point we would like to discuss is the one of  bitfield members
whose sizes match their underlying type.  Let's consider the following
example:

  struct Foo
  {
char a : 8;
char b : 8;
  };

If we compile such example with GCC it will add the `DW_AT_bit_size` and
`DW_AT_bit_offset` attributes to the `a` and `b` DIEs.

Clang on the other hand will not produce those attributes.


Since the specified bit size and the underlying type size are the same,
it would appear to me that specifying DW_AT_bit_size is redundant.

DW_AT_bit_offset was defined in DWARF Version 3 and 4, but has been
deprecated in DWARF Version 5.  See Section 5.7.6,
DW_AT_data_member_location and DW_AT_data_bit_offset.


On the debugger side, GDB currently considers a struct member as being
packed (i.e. part of a bitfield) if it has the `DW_AT_bit_size`
attribute present and is non-0.  Therefore, GDB will "understand"
what GCC produces, but not what Clang produces.


What is the difference in the layout for
  struct { char a; char b; } X;
and
  struct { char a:8; char b:8; } Y;

I would have to review the ISO C standard in detail, but I believe that
these are equivalent declarations.  In both structs, a is at byte offset
0 and b is at offset 1.

What is the difference in the DWARF description?


What Clang does seems to be a reasonable thing to do if one is only
interested in the memory layout of the type.  This however is not
sufficient in our case to decide how to handle such type when
placing/inspecting arguments in registers in the context of function
calls. In our ABI, bitfield members are passed packed together, while
two chars in a struct would be placed in separate registers.


It's not my position to critique an ABI, but this seems to require
additional packing and unpacking of char data.  Why not pack all struct
data into a minimum number of registers?  Or place all containing
entities in separate registers?


To clarify this situation, it would be helpful that a producer always
includes the DW_AT_bit_size attribute for bit field, which the standard
does not suggest nor require.


DWARF is a permissive standard, which means that at times there may be
different ways of describing the same source code.  DWARF is unlikely to
require that one description is prescribed and the other proscribed.



2 - Unnamed zero sized bitfield

Another case we met is related to unnamed fields with a size of 0 bits.
Such field is defined in the c++ standard as (in 9.6 Bit-Fields):

  > As a special case, an unnamed bit-field with a width of zero
  > specifies alignment of the next bit-field at an allocation unit
  > boundary

If we now consider an extended version of our previous example:

  struct Foo
  {
char a : 8;
char : 0;
char b : 8,
  };

Neither GCC nor Clang give any information about the unnamed bitfield.
As for the previous case, the presence of such field impacts how
arguments are passed during function calls on our target, leaving the
debugger unable to properly decide how to handle such cases.


The unnamed field is not accessible by any user code and, as the ISO C
standard describes, is only to insure that the following declarations
are aligned on a specific boundary which is associated with the type.

Other than forcing the alignment of following declarations, the :0
declaration has no other effect.


As for the previous case, both compilers can properly describe Foo's
memory layout using DW_AT_bit_offset.


Not that I agree with this contention, but DW_AT_bit_offset has been
deprecated.


It seems that such 0-sized field also has impact on ABI on other targets
such as armv7hl and aarch64 as discussed in [2].  Should the DWARF
specification give some guidance on how to handle such situation?


As mentioned in [2], in the x86-64 ABI "zero width 

Re: [Dwarf-Discuss] Support for SourceLink in DWARF

[Michael Eager via Dwarf-Discuss]

Hi Eugene --

Please work with Tony Tye (cc'ed), the champion on this issue, to draft 
a more complete proposal.  Much of the description on the Github 
reference for SourceLink is about the implementation in a PDB file and 
less about the what information is contained and how it is used.


On 5/4/22 18:54, Eugene Rozenfeld via Dwarf-Discuss wrote:

Hello,

I work on the Linux tools team at Microsoft and I'd like to comment on the 
issue  https://dwarfstd.org/ShowIssue.php?issue=181223.1 that proposes to add 
info similar to SourceLink to the DWARF format.
We are interested in pushing this forward both as a developer experience 
improvement and as a step in improving secure supply chain guarantees. It's 
important to be able to figure out where the sources come from if we want to 
check the binary integrity.

The issue discusses two approaches: one involves augmenting the DWARF format 
and the other one relies on buildid's and debuginfod servers. We believe the 
approach whereby an arbitrary URL for source retrieval (e.g., github, VSTS, 
etc.) can be specified offers greater applicability and flexibility over 
relying on buildid and debuginfod servers. For instance, it can accommodate 
scenarios where storing debuginfo along with sources on a debuginfod server may 
not always be feasible.

The issue discusses two approaches to modifying the  DWARF format: one is 
augmenting the existing file table to allow the specification of a URL (the 
proposed resolution) and the other one is a per CU URL table that would allow 
the equivalent of SourceLink wildcards. The tradeoff is simplicity vs. 
potential DWARF file size saving if many source files are involved in the 
compilation. We are ok with either resolution. The important thing is a 
standard way to encode the source file information so that the producers and 
consumers agree.

Thank you,

Eugene

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org




--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] How to interpret DW_AT_artificial tag?

[Michael Eager via Dwarf-Discuss]

On 2/28/22 13:11, David Blaikie via Dwarf-Discuss wrote:
On Mon, Feb 28, 2022 at 12:55 PM Greg Clayton via Dwarf-Discuss 
You could choose to not show this, but I find it is often easier to

show this information in case some compiler change in the future
marks something that you might want to see as artificial. For
example the "this" parameter to C++ methods is marked as artificial,
and people do want to see the "this" in the variables view. Granted
that is a variable vs a member variable.


Probably the important distinction there is that "this", while 
artificial, is named/usable in the source whereas the vtable isn't.


Either having some DWARF attribute to communicate that distinction, or a 
workaround might be to detect that the vtable name uses a reserved 
identifier could be good - I guess the reality is that DWARF consumers 
probably hardcode some sort of "this is the vtable pointer" -o so maybe 
we should have some DWARF attribute that communicates that, instead of 
relying on the string name of the member? Not sure.


This is a peculiarity of C++ where an artificial variable has a user-
accessible name.  Rather than have a special attribute to distinguish
this oddity, and since "this" is a reserved word in C++, it seems
easiest to simply check for this special case if the language is C++.
You can reasonably hard-code "this" knowing it can't be used for any
other purpose.  You cannot say the same about vtable pointers which can
have any (or no) name.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] What to do with Pascal properties?

[Michael Eager via Dwarf-Discuss]

In 5/28/21 7:11 AM, Joost van der Sluis via Dwarf-Discuss wrote:

Hi all,

I am one of the Free Pascal developers and also work on a debugger, 
aimed towards Free Pascal.


Now in Pascal there are 'properties'. Maybe you know these from c# which 
has something alike. Basically a property is an alias in a structure 
that links to other members of the same structure for reading, writing 
and/or storage-information.


Example:

type
   TMyClass=class
   private
     FProp: Integer;
     FPropIsStored: Boolean;
   protected
     function GetProp: Integer;
     function GetItem(const Index: Integer): string;
   public
     property IndividualItem[Index: Integer]: string read GetItem;
   published
     property Prop: Integer read GetProp stored FPropIsStored;
     property OtherProp: Integer read FProp write FProp;
     property Item2: string index 2 read GetItem;
   end;

var
   MyClass = TMyClass;

Reading MyClass.Prop effectively calls GetProp.

MyClass.Prop is read-only, and during streaming the information in 
FPropIsStored is being used.


MyClass.OtherProp is read/write, and is more or less an alias for the 
private FProp field.


MyClass.IndividualItem[6] is accessible like it is an array. And Item2 
has a fixed index.


I want to encode this propery into the Dwarf debug-information. At this 
moment we only generate debug-information for cases similar to 
MyClass.OtherProp by duplicating the debug-information of FProp with 
another visibility-class.


I've added the following attributes:
   DW_AT_FPC_property_read (0x3230)
   DW_AT_FPC_property_write (0x3231)
   DW_AT_FPC_property_stored (0x3232)

And then those attributes contain a link to the corresponding 
DW_TAG_members. This to keep the debug-information as compact as 
possible. Furthermore I've added the tag DW_TAG_FPC_property (0x4230) or 
else other debuggers may be confused when they encounter a DW_TAG_member 
with only one or more of these specific fpc-attributes.


I'll also have to add something like DW_AT_FPC_property_index to store 
the value of a fixed index.


I have two questions:
1. Am I on the good track, or did I miss something?


Generally, it looks like you are heading in the right direction.  I'd
have to look into the details much more to make any suggestions.

2. Maybe implementation specific, but maybe someone might have an idea: 
to generate the proposed debug-info, I need to add a label to every 
DW_TAG_member. Using global labels inside these structures though, may 
lead to all kinds of troubles, for example when a linker regards these 
labels as the start of a new section. Or on Darwin/macOS. Calculating 
the location of these tags is in principle possible I think, but 
difficult. Any tips here?


The general DWARF philosophy is to minimize relocations where ever
possible.  It isn't clear whether you are pointing the TAG
with a relocatable address or not.  Use offsets from the start of the
section where ever possible.

If the question is about local vs global symbols, many assemblers
will treat symbols which start with a period (e.g., .start) as
local and not export them to the object file symbol table.



This is a dwarfdump of the class-definition above with my current 
additions:


< 1><0x0123>    DW_TAG_class_type
   DW_AT_name  TMyClass
   DW_AT_byte_size 0x0010
< 2><0x012e>  DW_TAG_inheritance
     DW_AT_accessibility DW_ACCESS_public
     DW_AT_data_member_location  DW_OP_plus_uconst 0
     DW_AT_type  
< 2><0x0137>  DW_TAG_member
     DW_AT_name  FProp
     DW_AT_data_member_location  DW_OP_plus_uconst 8
     DW_AT_accessibility DW_ACCESS_private
     DW_AT_type  
< 2><0x0146>  DW_TAG_member
     DW_AT_name  FPropIsStored
     DW_AT_data_member_location  DW_OP_plus_uconst 12
     DW_AT_accessibility DW_ACCESS_private
     DW_AT_type  
< 2><0x015d>  
     DW_AT_name  IndividualItem
        
     DW_AT_type  
< 2><0x0175>  
     DW_AT_name  Prop
        
        
     DW_AT_type  
< 2><0x0187>  
     DW_AT_name  OtherProp
        
        
     DW_AT_type  
< 2><0x019e>  
     DW_AT_name  Item2
        
     DW_AT_type  
< 2><0x01ad>  DW_TAG_subprogram
   

Re: [Dwarf-Discuss] Retrieving variables, function address using dwarf

[Michael Eager via Dwarf-Discuss]

On 3/10/21 10:38 PM, Archana Deshmukh wrote:
Thanks Michael for the response. Actually, I have only this much 
information.


I need to get information related to

  For global variables , I read the address "55b51afea000" from     > 
/proc//maps file. I use DW_OP_addr parameter to retrieve the address.


  55b51afea000 + DW_OP_addr gives me the address of global variables.

For function, I read the address "55b51afea000" from     > 
/proc//maps file.. I use DW_AT_low_pc parameter to retrieve the 
function starting address


Now, I need to read the local variables address. As I am not executing 
the process, I cannot use registers. I need to use DW_OP_call_frame_cfa. 
I am not able to understand how to retrieve addresses using 
DW_OP_call_frame_cfa.


Any pointer or suggestion are most welcome.


Attach to the process using ptrace() and you can get process registers.



Best Regards,
Archana




On Tue, Mar 9, 2021 at 11:07 PM Michael Eager > wrote:


It's difficult to offer advice with such a spare description.

You might read the executable and relocate the .debug_info and
other debug sections using the process map.  If you have the
process image, this probably would not be necessary.

On 3/8/21 1:49 AM, Archana Deshmukh via Dwarf-Discuss wrote:
 > Hello,
 >
 > I have a pinatrace.out and process map of a file.
 > With this input, I need to build a symbol table.
 >
 > Best Regards,
 > Archana Deshmukh
 >
 > On Sun, Mar 7, 2021 at 10:29 AM Archana Deshmukh
 > mailto:desharchan...@gmail.com>
>>
wrote:
 >
 >
 >
 >     -- Forwarded message -
 >     From: *Michael Eager* mailto:ea...@eagercon.com> >>
 >     Date: Sat, Mar 6, 2021 at 10:53 PM
 >     Subject: Re: [Dwarf-Discuss] Retrieving variables, function
address
 >     using dwarf
 >     To: Archana Deshmukh mailto:desharchan...@gmail.com>
 >     >>,
mailto:dwarf-discuss@lists.dwarfstd.org>
 >     >>
 >
 >
 >     On 3/5/21 8:28 PM, Archana Deshmukh via Dwarf-Discuss wrote:
 >      > I need to read the address of local variable, global variable,
 >     function
 >      > name and function arguments from the process.
 >      >
 >      > For global variables , I read the address "55b51afea000" from
 >      > /proc//maps file. I use DW_OP_addr parameter to
retrieve the
 >     address.
 >      > 55b51afea000 + DW_OP_addr gives me the address of global
variable.
 >      >
 >      > I need to read the stack segment, heap. Is there any way
to read
 >      > segments? DW_AT_segment parameter seems to be for 16 bit.
 >      >
 >      > I need to read the following process map using dwarf.
 >      >
 >      > Any suggestion, pointers are welcome.
 >      >
 >      > 55b51afea000-55b51afeb000 r-xp  fd:00 5902563
 >
 >     Can you explain what you are trying to do?
 >
 >     Usually a DWARF consumer (a debugger) does not need to read the
 >     process memory map.  All of the information you mention is in
 >     the DWARF data.  You may need to relocate addresses in the DWARF
 >     debug data.
 >
 >     DWARF does not contain information about the process memory
 >     layout, such as the location of the heap or the start of the
 >     stack.
 >
 >     --
 >     Michael Eager
 >
 >
 > ___
 > Dwarf-Discuss mailing list
 > Dwarf-Discuss@lists.dwarfstd.org

 > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

 >

-- 
Michael Eager




--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

[Michael Eager via Dwarf-Discuss]

On 3/10/21 1:28 PM, David Blaikie wrote:
On Wed, Mar 10, 2021 at 1:21 PM Cary Coutant > wrote:


 > Speculation beyond the original question:
 > Given that it's a pretty common/core feature of a debugger to
call functions, perhaps a start would be some way for the producer
to communicate, via DWARF, that it has changed the ABI of a function
and so the consumer should not try to synthesize calls to it.
Providing much more functionality than that I think will amount to
encoding the ad-hoc ABIs that compilers create in these situations
(possible, but a fairly non-trivial proposal/enhancement to DWARF)

I believe that's what DW_AT_calling_convention and DW_CC_nocall are
for (Section 3.3.1.1).


Oh, sweet - yep, that looks like the ticket indeed.

"If the value of the calling convention attribute is the constant 
DW_CC_nocall, the subroutine does not obey standard calling conventions, 
and it may not be safe for the debugger to call this subroutine."


All that says is that you can't call the function.  It doesn't
describe how to call functions with non-ABI calling conventions.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

[Michael Eager via Dwarf-Discuss]

On 3/9/21 7:05 AM, Andrew Cagney via Dwarf-Discuss wrote:

Part of a typical Application Binary Interface is to specify the
function calling convention.  Several uses are:

- ensuring function calls across interface boundaries work (function
in one object calls function in second object)
- the debugger supplementing the debug information describing the
location of parameters
- the debugger implementing inferior function calls

Typically calls both between and within object files (DWARF
compilation unit) follow the ABI (with exceptions for things like
__mul, but good ABIs even defined those).

Technically, however, only functions visible via an interface need
comply with the ABI.  This means that:

- for simple objects, local functions; and
- with link-time-optimization, everything except library interface functions

are fair game for ABI non-compliant call optimizations.

Is anyone aware of a compiler doing this (I figure with LTO there's a
strong incentive)?  And if so, how is this described to the debugger.
The ABI / calling-convention is no longer on hand for filling in the
blanks.


This is an instance of a more general issue: debugging optimized code.

DWARF has ways to describe some of the optimizations which a compiler
can perform, such as inlining.  This is because at least some of the
semantics of the process of inlining are well defined.  Even then, a
debugger calling an inlined function is generally not possible, unless
there is a non-inlined instance.

There are a range of optimizations which a compiler can perform as
long as the program performs as if the optimization was not done.
These include eliminated code, merged code, duplicated code, non-ABI
calls, non-ABI returns, and lots more.  DWARF describes the
correspondence between source code and executable instruction, the
locations of arguments and variables, and how to walk the stack.

This seems to be adequate to debug many optimized programs, even if it
is not a complete description of the optimizations.

If you want a debugger to be able to call a function which has been
merged (partially or completely) into another function, or which has
a streamlined non-ABI compliant call/return sequence, DWARF does not
provide this information.  There might be a way to describe this
piecemeal, addressing this one instance of the general issue of how
to debug optimized code.  Or perhaps there is a more general way to
describe optimizations.


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Retrieving variables, function address using dwarf

[Michael Eager via Dwarf-Discuss]

It's difficult to offer advice with such a spare description.

You might read the executable and relocate the .debug_info and
other debug sections using the process map.  If you have the
process image, this probably would not be necessary.

On 3/8/21 1:49 AM, Archana Deshmukh via Dwarf-Discuss wrote:

Hello,

I have a pinatrace.out and process map of a file.
With this input, I need to build a symbol table.

Best Regards,
Archana Deshmukh

On Sun, Mar 7, 2021 at 10:29 AM Archana Deshmukh 
mailto:desharchan...@gmail.com>> wrote:




-- Forwarded message -
From: *Michael Eager* mailto:ea...@eagercon.com>>
Date: Sat, Mar 6, 2021 at 10:53 PM
Subject: Re: [Dwarf-Discuss] Retrieving variables, function address
using dwarf
To: Archana Deshmukh mailto:desharchan...@gmail.com>>, mailto:dwarf-discuss@lists.dwarfstd.org>>


On 3/5/21 8:28 PM, Archana Deshmukh via Dwarf-Discuss wrote:
 > I need to read the address of local variable, global variable,
function
 > name and function arguments from the process.
 >
 > For global variables , I read the address "55b51afea000" from
 > /proc//maps file. I use DW_OP_addr parameter to retrieve the
address.
 > 55b51afea000 + DW_OP_addr gives me the address of global variable.
 >
 > I need to read the stack segment, heap. Is there any way to read
 > segments? DW_AT_segment parameter seems to be for 16 bit.
 >
 > I need to read the following process map using dwarf.
 >
 > Any suggestion, pointers are welcome.
 >
 > 55b51afea000-55b51afeb000 r-xp  fd:00 5902563

Can you explain what you are trying to do?

Usually a DWARF consumer (a debugger) does not need to read the
process memory map.  All of the information you mention is in
the DWARF data.  You may need to relocate addresses in the DWARF
debug data.

DWARF does not contain information about the process memory
layout, such as the location of the heap or the start of the
stack.

-- 
Michael Eager



___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org



--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

[Michael Eager via Dwarf-Discuss]

On 3/9/21 7:13 AM, Frank Ch. Eigler via Dwarf-Discuss wrote:

As I understand it, the location of*function return values*  is
however a gap in DWARF, and a consumer tool must resort to ABI specs.
(Thus the elfutils dwfl_module_return_value_location() function.)  I'm
sure there's a Reason for this, but having worked on a consumer, it'd
be handy if DWARF did explicitly identify the return value location
too.


DWARF does not duplicate information which is documented in the ABI
or in other information which is shared by compilers and debuggers.
For example, DWARF does not describe the calling convention for a
function.  Producers and consumers are expected to know this info.

The rationale is that duplicating shared ABI knowledge would greatly
increase the size of a debug file, while not improving the ability
to debug a program.

For example, DWARF describes the arguments to a function.  It doesn't
describe the calling convention, which registers are preserved, which
are clobbered, or anything else which is specified by the ABI.  In
most ABIs, the location of a function return value is similarly
constrained.  If there are multiple calling conventions, this is
identified to allow a debugger to generate a valid call to a function.

DWARF only contains information which describes what a compiler
generates which cannot be unambiguous determined by knowledge of the
ABI.  A limited exception is the CFI, which in many cases mirrors the
ABI.

If there are occasions when a compiler might place a function return
value in a variety of different locations, not constrained by the
ABI, a DWARF attribute might be useful.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Retrieving variables, function address using dwarf

[Michael Eager via Dwarf-Discuss]

On 3/5/21 8:28 PM, Archana Deshmukh via Dwarf-Discuss wrote:
I need to read the address of local variable, global variable, function 
name and function arguments from the process.


For global variables , I read the address "55b51afea000" from 
/proc//maps file. I use DW_OP_addr parameter to retrieve the address.

55b51afea000 + DW_OP_addr gives me the address of global variable.

I need to read the stack segment, heap. Is there any way to read 
segments? DW_AT_segment parameter seems to be for 16 bit.


I need to read the following process map using dwarf.

Any suggestion, pointers are welcome.

55b51afea000-55b51afeb000 r-xp  fd:00 5902563


Can you explain what you are trying to do?

Usually a DWARF consumer (a debugger) does not need to read the
process memory map.  All of the information you mention is in
the DWARF data.  You may need to relocate addresses in the DWARF
debug data.

DWARF does not contain information about the process memory
layout, such as the location of the heap or the start of the
stack.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] HTML documentation for DWARF

[Michael Eager via Dwarf-Discuss]

On 3/1/21 2:53 PM, Konrad Kleine via Dwarf-Discuss wrote:
On a side note, the comment function doesn't work: 
http://www.dwarfstd.org/Comment.php  .


The verification doesn't work there: "Verification failed. Please go 
back and try again."


Make sure that you have filled in all fields before submitting comment.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] DW_AT values unknown to me.

[Michael Eager via Dwarf-Discuss]

Green Hills has never contacted us about DWARF implementation or 
submitted any proposals to the DWARF Committee.


Many years ago, I was on an ABI committee with Greg Davis, who I believe 
is Director of Engineering at GHS.  You might contact him for 
information about these attributes.  The last email I have for him is 
gda...@ghs.com.


On 2/17/21 3:28 PM, John DelSignore via Dwarf-Discuss wrote:

You probably already know this, but I'm pretty sure that "GHS" is Green Hills 
Software: https://www.ghs.com/products/compiler.html

TotalView supported their compiler on the BBN Butterfly in the early '90s, but 
that predated DWARF support. Maybe someone at Green Hills can tell you what 
they mean.

Cheers, John D.

On 2/17/21 6:07 PM, David Anderson via Dwarf-Discuss wrote:

I try to make the dwarf.h  file complete in its set of DW_AT values,
including non-standard entries I know nothing about.

I recently came across a few whose proper spelling is
completely unknown to me. So I made up names.
Browser searches revealed nothing so far.

/*  From DWARF2 DW_AT_producer GHS C 2012.5.4 [dual] */
#define DW_AT_GHS_unknown1 0x2083
#define DW_AT_GHS_unknown2 0x2087
#define DW_AT_GHS_unknown3 0x2085
#define DW_AT_GHS_unknown4 0x2086
#define DW_AT_GHS_unknown5 0x2092

If anyone can come up with the proper spellings and let me know
what those are I would appreciate it.

Thanks in advance.
David Anderson (libdwarf)
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org



--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

[Dwarf-Discuss] DWARF Committee resumes meetings

[Michael Eager via Dwarf-Discuss]

The DWARF Debugging Standard Committee (http://dwarfstd.org) is planning 
to resume meetings starting in February.  The DWARF debugging file 
format, as you likely know, is widely used by compilers and debuggers to 
support source level debugging.  The Committee released Version 5 of the 
DWARF Standard in 2017 and will start work on Version 6.


The committee consists of more than 20 committee members from a broad 
cross-section of the compiler and debugger development community, 
representing a dozen companies and including a number of independent 
developers, working on both proprietary and open source products.


A list of the current proposals or issues can be found on the Open 
Issues web page:  http://dwarfstd.org/Issues.php.  If you would like to 
submit a comment, proposal, or issue, go to the Public Comment page: 
http://dwarfstd.org/Comment.php.


If you are interested in participating on the DWARF Committee please 
contact me privately.


--
Michael Eager, DWARF Committee Chair
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] John Bishop retiring from DWARF Committee

[Michael Eager via Dwarf-Discuss]

Hi John --

It looks like this went to the public DWARF discussion mailing list. 
I'm CCing the DWARF Committee mailing list.


Thanks for your participation on the DWARF Committee.  You contributions 
have been greatly appreciated.


On 9/11/20 1:59 PM, Bishop, John E via Dwarf-Discuss wrote:

All,

I will take this as my cue to retire from the DWARF Committee.

When I joined many years ago, I was working on a debugger.  For the last 
several years I've been maintaining and enhancing a Fortran run-time library.  
As a result, debugger issues and DWARF are not part of my work-life and I can't 
give them as much attention as they deserve.  Further, my company will continue 
to be represented on the Committee, and represented by someone who is actively 
working on debug-code generation.

I've enjoyed being on the committee these many years.  It's good to be part of 
a group which works well together and is trying to do the right thing.  Thanks 
and fare well!

-John

-Original Message-
From: Dwarf-Workgroup  On Behalf Of 
Jason Merrill via Dwarf-Workgroup
Sent: Monday, September 7, 2020 5:39 PM
To: Michael Eager 
Cc: dwarf-workgr...@lists.dwarfstd.org
Subject: Re: [Dwarf-Workgroup] Resume DWARF Committee meetings?

I think it makes sense to start up again.

On Sat, Sep 5, 2020 at 3:06 PM Michael Eager via Dwarf-Workgroup 
 wrote:


Hi All --

I'd like to get your feedback about whether to resume monthly DWARF
Committee meetings.

Version 5 of the DWARF Standard was released in early 2017 and our
last regular meeting was about the same time.  We have been on hiatus
for over three years.

We have 59 items on the issues list.  They are a mix: some may be
simple, some may be complex, some may have become moot as time has
passed since they were submitted.  There has been a recent flurry of
messages on the DWARF-Discuss mailing list.

We currently have 26 committee members.  This is a large committee and
may become unwieldy.  As you may know, I like to see all committee
members take an active role in evaluating all proposals and creating
the next version of the DWARF Standard.  In the past, we have had
committee members who wanted keep an eye on what the committee was
doing, or were only interested in participating on the issue they
submitted.  We do not have observer positions on the committee.  If
there are people who no longer wish to be on the DWARF Committee, please let me 
know.

I'm happy to resume meetings.  I'm equally happy to remain on hiatus.
Please let me know your thoughts.

--
Michael Eager
___
Dwarf-Workgroup mailing list
dwarf-workgr...@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-workgroup-dwarfstd.org



___
Dwarf-Workgroup mailing list
dwarf-workgr...@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-workgroup-dwarfstd.org
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org



--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] More on DW_AT_str_offset_base debug_str_offsets.dwo confusion

[Michael Eager via Dwarf-Discuss]

On 9/1/20 6:59 AM, David Anderson wrote:

Mike Eager: please delete the new issue 200831.1 as it is simply wrong.


Done.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

[Dwarf-Discuss] Subscriptions to DWARF-Discuss mailing list

[Michael Eager via Dwarf-Discuss]

I've noticed a number of what appear to be invalid subscriptions to the 
DWARF-Discuss mailing list, for example, stop-spoof...@amazon.com or 
spamred...@gmail.com.   Invalid email addresses like this increase the 
number of notifications I see for bounced messages and may annoy the 
recipients, if delivered.  I do not wish the DWARF-Discuss mailing list 
to be used to deliver spam.


Most DWARF-Discuss mailing list subscribers provided their name when 
they subscribed.  On September 1, I will go through the DWARF-Discuss 
subscriber list and if the member name is blank or does not appear to be 
a name, or if the email address appears to be invalid, the member will 
be unsubscribed.


You can update your subscription by following the link at the bottom of 
this message.  Thanks for your understanding.


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] modeling different address spaces

[Michael Eager via Dwarf-Discuss]

On 7/20/20 8:24 AM, Metzger, Markus T wrote:

Hello Michael,


We'd also want an unbounded piece operator to describe partially registerized
unbounded arrays, but I have not worked that out in detail, yet, and we're a bit
farther away from an implementation.


Can you describe this more?


Consider a large array kept in memory and a for loop iterating over the array.  
If that
loop gets vectorized, compilers would load a portion of the array into 
registers at the
beginning of the loop body, operate on the registers, and write them back at 
the end
of the loop body.

The entire array can be split into three pieces:
- elements that have already been processed: in memory
- elements that are currently being processed: in registers
- elements that will be processed in future iterations: in memory

For unbounded arrays, the size of the third piece is not known.


When would you need to know the third piece?

How is this different from a non-vector processor doing an optimized 
string operation, loading 4 characters into a register at a time?  If 
the string is nul-terminated, the string length might be unknown.


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] modeling different address spaces

[Michael Eager via Dwarf-Discuss]

On 7/20/20 1:43 AM, Metzger, Markus T via Dwarf-Discuss wrote:


I also have a small proposal for describing locations as function of the SIMD 
lane by
adding a DW_OP_push_simd_lane operator and introducing stack variants for piece
operators.
  
I have a write-up ready but wanted to wait until we have a public implementation.

Is that the right order?  Or would you rather want to review proposals right 
away.


I'm not sure what a SIMD lane is.  There are a number of architectures 
which support SIMD, such as the AVX extension in x86.  We try to 
describe functionality in generic terms as much as possible so that it 
can be used with a variety of architectures.


We'd be happy to see your proposal.  Often an implementation is a good 
proof of concept, but getting feedback on a design early in the process 
can be a guide to that implementation and avoids changes later.



We'd also want an unbounded piece operator to describe partially registerized
unbounded arrays, but I have not worked that out in detail, yet, and we're a bit
farther away from an implementation.


Can you describe this more?

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Segment selectors for the range list table.

[Michael Eager via Dwarf-Discuss]

On 7/16/20 2:57 PM, David Blaikie wrote:



On Thu, Jul 16, 2020 at 2:05 PM Michael Eager 

You appear to be starting with a counterfactual premise and using that
to postulate a problem where none exists.


Sorry - I seem to be misunderstanding what you mean by "there are no 
restrictions on where code or data are located" - I understood that to 
mean different bits of code could be in different segments.


It does no one good when you take a comment about one point 
(.debug_aranges) and contort it to apply to an unrelated point 
(DW_AT_segment).


Reread my previous comment about the meaning of segment as used in 
DW_AT_segment.   You apparently want it to mean something different.



As previously stated, DW_AT_segment provides a way to represent x86
segmented addressing.  Each segmented address is mapped to an
address in
a linear address space.  The mapped address can be used in the ranges.


Where does the spec say that? How do we construct an answer to the 
original question from this thread from the words in the spec?


There are many things that the spec does not say about implementation. 
We sometimes suggest best practices, but we don't require implementors 
to follow them.  The DWARF spec is also not written to prevent 
implementors from doing things badly.


Providing an example of the use of DW_AT_segment provides a strong hint 
of how it may be used, without constraining it to one specific 
architecture, or preventing it from being used in other ways.  When we 
have had discussions about whether to give more specific implementation 
details, we have frequently decided to let matters go with a hint, 
rather than a prescription.


While we cannot prevent people from misreading or misinterpreting the 
DWARF spec, we try to answer questions as they arise.


Having been told how address ranges might be implemented for x86 
segmented addresses, is there more to add?


I don't especially have a need for segmented addresses myself - so I may 
not be the best person to push for changes/clarifications here - I was 
trying to answer the original poster's question using what I can see 
from the spec.


It's rarely beneficial to get into a hypothetical debate.  If you have 
no use case and are just postulating problems for which there is no 
evidence, there isn't much to be gained pursuing this.



You appear to be reading the standard to mean something other than what
it says.  FORM_addrx is a method to compress FORM_addr, nothing more.


But it describes segmented addresses - it says so specifically, doesn't 
it? Using the same wording that is used to describe segmented addresses 
elsewhere in the spec.


DWARF uses the same description for segmented addresses almost 
everywhere that an address is used.  This is for consistency.  The 
meaning is the same everywhere.



--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Segment selectors for the range list table.

[Michael Eager via Dwarf-Discuss]

On 7/16/20 1:36 PM, David Blaikie wrote:



On Thu, Jul 16, 2020 at 1:07 PM Michael Eager > wrote:


 > Perhaps it's more like Paul was postulating - that the spec
assumes code
 > is in a code segment/doesn't need to be clarified. (but that gets
a bit
 > confused in debug_aranges - if it only is meant to contain code (not
 > data), why does it need a segment selector - and also in the DIEs
- if
 > code is always in a known/assumable segment then why can you vary
 > segment for low_pc/high_pc/ranges?)

No, the spec says what it says.   There are no restriction on where
code
or data are located.


OK - then if subprograms can be in different segments, how would the 
ranges on the CU be used to describe that? It seems to me that a range 
list can't contain regions in more than one segment, which presents a 
problem for describing such a situation, no?


You appear to be starting with a counterfactual premise and using that 
to postulate a problem where none exists.


As previously stated, DW_AT_segment provides a way to represent x86 
segmented addressing.  Each segmented address is mapped to an address in 
a linear address space.  The mapped address can be used in the ranges.


(speaking of header consistency - it's a pity the debug_macro section 
didn't end up with a more consistent header that started with a length, 
then a version - without the length prefix it'll be hard to skip over 
these in a consumer (especially something like a dumper) if their 
version is unknown (in future versions, for instance))


Rather than lard a thread with extraneous comments about unrelated 
issues, submit a comment on the DWARF Standard Public Comment page: 
http://dwarfstd.org/Comment.php



 > debug_addr supports segment selectors - in the debug_addr header
it has
 > a field for "segment selector size" and the entries in the
address list
 > are "segment/address pairs.".
 >
 > So now there's two ways a segment selector for an address could be
 > specified - if you had a DW_TAG_subprogram with a DW_AT_low_pc using
 > addrx into a debug_addr with a non-zero segment selector and the
 > subprogram also had a DW_AT_segment, wonder which one's meant to win.

Again, FORM_addrx doesn't mean the same as DW_AT_segment.


The spec seems to use exactly the same language. All the addresses seem 
to say they only contain the offset portion of the address - so they'd 
all need a segment selector to resolve which segment they should be 
relative to, right? But some of them don't have a segment selector - 
though the spec says loc/range/etc should be relative to the segment on 
the DIE that references the loclist/rnglist/address - but then the 
debug_addr has redundant (or possibly contradictory... ) segment 
selectors and the range/loclists could only describe things in one 
segment (so you couldn't use CU ranges to describe one function in one 
segment and another function in a different segment)


There are always ambiguities in written text.  If you have a specific 
comment about wording in the DWARF Specification, please submit a Public 
Comment.



They are orthogonal concepts.  Compression techniques, like FORM_addrx,
should not be used to describe architectural features.


I agree there clearly shouldn't be something you can express in a 
debug_rnglist or debug_loclist (or a DIE attribute using FORM_addrx) 
with the *x forms that you can't describe with the non-*x forms, but 
from the semantics represented, it looks like that's the case, even if 
it's not how it should be.


There are no semantics represented in DWARF.

You appear to be reading the standard to mean something other than what 
it says.  FORM_addrx is a method to compress FORM_addr, nothing more.


I think the language that's missing in debug_loclists/debug_rnglists (& 
was missing from debug_range/debug_loc too) is that the addresses should 
be preceeded by their segment - same as debug_aranges and debug_frame? 
(& in rnglist/loclist, the segment selector would go in any form that 
has an address in it)


Please file a Public Comment.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Segment selectors for the range list table.

[Michael Eager via Dwarf-Discuss]

Perhaps it's more like Paul was postulating - that the spec assumes code 
is in a code segment/doesn't need to be clarified. (but that gets a bit 
confused in debug_aranges - if it only is meant to contain code (not 
data), why does it need a segment selector - and also in the DIEs - if 
code is always in a known/assumable segment then why can you vary 
segment for low_pc/high_pc/ranges?)


No, the spec says what it says.   There are no restriction on where code 
or data are located.



AFAIK, all addresses can be segmented addresses, except in the line
table where it isn't needed.

Perhaps we should have (long ago) required flat/linear addresses for
x86
instead of segmented addresses.


What's the line table's segment_selector_size (in the DWARFv5 header) 
for? (this sort of agrees and disagrees with you - it's there, but it's 
not used in any part of the debug_line format that I can see)


It may be there for consistency across all headers.

debug_addr supports segment selectors - in the debug_addr header it has 
a field for "segment selector size" and the entries in the address list 
are "segment/address pairs.".


So now there's two ways a segment selector for an address could be 
specified - if you had a DW_TAG_subprogram with a DW_AT_low_pc using 
addrx into a debug_addr with a non-zero segment selector and the 
subprogram also had a DW_AT_segment, wonder which one's meant to win.


Again, FORM_addrx doesn't mean the same as DW_AT_segment.

They are orthogonal concepts.  Compression techniques, like FORM_addrx, 
should not be used to describe architectural features.


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] modeling different address spaces

[Michael Eager via Dwarf-Discuss]

On 7/16/20 11:51 AM, David Blaikie wrote:



On Thu, Jul 16, 2020 at 11:41 AM Robinson, Paul via Dwarf-Discuss 
The example that most often comes up is Harvard architectures.  As it

happens, I think it's nearly always obvious from context whether a given
address is data-segment or code-segment.  The only time it's not,
that I'm
aware of, is in the .debug_aranges section, where addresses are
associated
with compile-units without any indication of whether they are code
or data
addresses.  I've heard arguments that .debug_aranges should only
have code
addresses in it, but I don't think that's what the spec says.


Curious - the spec doesn't seem to read that way to me - and if that 
were its goal, it seems like DW_AT_segment wouldn't really be needed. 


As Paul said, DW_AT_segment is not generally needed to describe a 
Harvard architecture.


DW_AT_locations would always be data, DW_AT_high/low/ranges would always 
be code, etc? The spec... specifically says DW_AT_segment applies to 
high/low/ranges, and describes a parent-DIE delegation scheme that seems 
to suggest that some DIEs could have one segment, and others could have 
a different segment - but no way for ranges to have different segments 
in different parts of the same range list, which seems to be at odds 
with the ability to vary segment across a DIE tree - you couldn't put a 
ranges at the top of such a variegated tree...


On some (many?) architectures, data and code may be interspersed, for 
example, to place constant data with the executable text.


DIEs can have different DW_AT_segments.

Entries in .debug_aranges have segment, offset, and length.

What is the use case for having multiple segments in a range list?

(& yeah, the arange situation crossed my mind too - on both counts you 
noted (that it needs it, but that it may not - because some 
interpretations suggest it should only contain code addresses anyway))


As Paul mentioned, that's not what the spec says.

& not sure how any of this resolves the "but debug_addr has segment 
selectors"


nor "what's the point of segment selector size in debug_rnglists, 
debug_loclists, and debug_line" - none of those sections seem to contain 
segment selectors, so why do their headers describe the size of such a 
thing?


Location lists contain segment, offset, and length.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] modeling different address spaces

[Michael Eager via Dwarf-Discuss]

On 7/16/20 10:26 AM, John DelSignore via Dwarf-Discuss wrote:

FYI, Tony Tye and his team at AMD created a DWARF Proposal for heterogeneous 
debugging, which is generally useful but required to debug optimized code for 
GPUs. It directly addresses the issue of how to model different address spaces 
and makes location descriptions first-class objects that can be push onto the 
evaluation stack.

https://llvm.org/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.html

AFAIK, these changes will be made to LLVM and there is interest in adding to 
the DWARF standard eventually.


As mentioned in the past, I would be pleased to see proposals submitted 
for these changes.


I would like to avoid the situation where we have an informal proposal 
lacking specific changes to the DWARF standard, matched with an 
implementation which claims to match the proposal.  That's the opposite 
of standardization.


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] modeling different address spaces

[Michael Eager via Dwarf-Discuss]

On 7/16/20 10:06 AM, Todd Allen via Dwarf-Discuss wrote:

Markus, Michael, David, Xing,

I always assumed that the segment support in DWARF was meant to be more general,
and support architectures where there was no single flat memory, and so the
segments were necessary for memory accesses.  I personally have not dealt with
any architectures where DW_AT_segment came into play, though.


It is phrased in a way to make it less architecturally specific.  That's 
in keeping with our desire to prevent DWARF from including architecture 
specific specifications.  For example, we don't want to say "on ARM do 
this" but on "MIPS do that".  DWARF doesn't specify how the translation 
from segmented to linear addresses is done.



Certainly x86 does not fall into that "truly distinct segments" category, at
least not in modern times.  The segment registers there (fs & gs, for example)
are an indirect way of specifying a base address within the flat address space.
They usually end up being used for thread-specific data structures where each
thread has a different segment selector which implies a different base address.
And it requires a syscall to interact with the base addresses, at least on
Linux.  The other segment registers (cs, ds, ss) are set-and-forget by the OS
typically.


As soon as you mention segment registers, you move from the static 
description of the memory image to the dynamic description of the 
execution.  DW_AT_segment is a static description of memory layout.  The 
computations in a DWARF expression (which may reference a segment 
register) are only relevant when looking at an executing program (or a 
memory dump) and you have a PC context.


The Intel terminology describing the static memory addressing as 
segments with the dynamic segment registers leads to this confusion.



The CUDA architecture is an interesting case.  It doesn't use DW_AT_segment at
all.  But it does use the DW_AT_address_class attribute to specify CUDA segments
(e.g. Global, Local, Shared, among many others) for variables and/or types.  So
it's fairly fine-grained.  You can, for example, have a shared pointer to a
global pointer to a local integer, and the DW_AT_address_class attribute can
convey that.

Some of those CUDA segments are for radically different sorts of memory
(e.g. very low latency Shared memory vs. high latency Global memory).  But other
distinctions seem more gratuitous (e.g. Param vs. Global memory).  I assume that
there's a CUDA under-the-hood mapping of many of the segments to regions of a
flat Global address space in there, but the CUDA architectures & drivers
deliberately hide that mapping.  So effectively you end up with all the segments
being distinct, as far as a debugger can tell.


CUDA address spaces or a DSP with multiple distinct address spaces are 
what would conventionally be described as segmented memory.  I think 
that using the DW_AT_address_space would be reasonable.




On Thu, Jul 16, 2020 at 09:23:51AM +, Dwarf Discussion wrote:

Hello,



What would be the recommended way to model variables that are allocated to
different address spaces?



I found DW_OPT_xderef for dereferencing address-space qualified pointers
but the resulting memory location description wouldn't have an
address-space qualifier.



I found DW_AT_address_class, which allows attaching an integer, which
could represent the address-space.  This sounds pretty close.  I'm a bit
thrown off by the example, though.



Thanks,

Markus.





--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] modeling different address spaces

[Michael Eager via Dwarf-Discuss]

On 7/16/20 2:23 AM, Metzger, Markus T via Dwarf-Discuss wrote:

Hello,

What would be the recommended way to model variables that are allocated 
to different address spaces?


Can you describe the architecture a bit?

I found DW_OPT_xderef for dereferencing address-space qualified pointers 
but the resulting memory location description wouldn’t have an 
address-space qualifier.


DW_OPT_xderef translates from an architecturally defined memory 
reference including an address space into a linear address space 
(generic type).  DWARF doesn't support computations on address-space 
qualified addresses, although using a typed stack, this could be an 
extension.


I found DW_AT_address_class, which allows attaching an integer, which 
could represent the address-space.  This sounds pretty close.  I’m a bit 
thrown off by the example, though.


Which example?

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Segment selectors for the range list table.

[Michael Eager via Dwarf-Discuss]

On 7/15/20 9:49 PM, David Blaikie wrote:



On Wed, Jul 15, 2020 at 7:07 PM Michael Eager via Dwarf-Discuss 
<mailto:dwarf-discuss@lists.dwarfstd.org>> wrote:


Segmented addresses have been in the DWARF specification since
Version 2
   and AFAIK have not been changed since that time.  DWARF V5 did
not add
any functionality to segmented addresses that was not present in DWARF
V2/3.  At least, there was no intention to do so.  Segmented addresses
are described in Section 2.12.

A segmented address maps into a linear address in a processor-specific
fashion. 



That seems at odds with the non-normative text of 2.12 "In some systems, 
addresses are specified as offsets within a given segment rather than as 
locations within a single flat address space."


That means that an x86 address could be represented as offset 0x1234 in 
segment 0x, which would translate to 0x0+0x1234=0x45674.  Note 
that x86 permits aliases, so that offset 0x0124 in segment 0x4555 is the 
same address.


DWARF sometimes uses wording which is intended to generalize a concept. 
Conceivably, another architecture could use the same DWARF attribute in 
a similar way.  That's why the non-normative text says "some systems" 
rather than specifically referencing x86.  But we do have that as the 
only example listed in the table.


And also would be confusing to me - if there is a contiguous linear 
address space, why would DWARF need to specify the use of a segment 
selector, and why do some references to addresses allow the inclusion of 
a segment selector and some don't? Why not just always use the 
non-segmented address description for DWARF?


So that a compiler can generate segment address values and offsets 
independently.  An x86 code generator may not know what segment it is 
generating code in.


AFAIK, all addresses can be segmented addresses, except in the line 
table where it isn't needed.


Perhaps we should have (long ago) required flat/linear addresses for x86 
instead of segmented addresses.


& I don't find any mention of this idea that some addresses are absolute 
and some are segment-relative in 2.12 - it does say that "If none of the 
entries in the chain of parents for this entry back to its containing 
compilation unit entry have DW_AT_segment attributes, then the entry is 
assumed to exist within a flat address space." - as though a flat (I 
assume this is synonymous with "linear"?) address space is distinct from 
the segmented address space being discussed otherwise?


Flat address space == linear address space.

From a certain perspective, x86 memory space is broken up into 65K 
16-byte segments mapped onto a 256K linear address range.




AFAIK, only the Intel 8086 and descendants have this
functionality.  (It's a many to one mapping in the 8086 implementation,
but that's a problem for a bygone era.)  There's a reference to i386
memory models in Table 2.7.

DWARF assumes a linear address space.  A segmented address maps to a
specific address in this linear address space.  The entries in
DW_AT_ranges for subprograms with different segment addresses would
usually be referenced by their address in the linear address space.  If
DW_AT_ranges has a DW_AT_segment, this is an indication that the
debugger is to perform the processor-specific computation to translate
the segment-address pair to the linear address.

There is no need to do anything with segments in the line table, since
the line table contains addresses in the linear address space.

There is some (perhaps considerable) confusion in terminology in the
x86
world, because the x86 has multiple segment registers which on other
processors would be called base registers.  The values in these
registers reference memory segments and are added to whatever offset is
contained in the program to generate an address.  These segment
registers, and the memory segments which they point to, are NOT the
segments represented by DW_AT_segment.

Re "reading the segment selector" and "addrx encoding":  The addresses
in DWARF DIEs are static, not dynamic.  There is no register+offset
encoding, and processor registers are not read to determine where a
subprogram is in memory.


Sorry, I don't quite follow the connections between all those statements.


Perhaps I didn't understand your comments about "reading the segment 
selector" and "addrx encoding".


TL;DR:
DW_AT_segment was designed to describe x86 memory model addresses: 
https://en.wikipedia.org/wiki/Intel_Memory_Model.


Possibly other architectures can use it, but I'm not familiar with any 
that do.



2.17 says that if a DIE has a DW_AT_high_pc and DW_AT_segment, then the 
high_pc is relative to the specified segment. That's a bit redundant if 
high_pc uses FORM_addrx, because the address 

Re: [Dwarf-Discuss] DW_AT_rnglists_base in DW_TAG_skeleton_unit

[Michael Eager via Dwarf-Discuss]

On 7/1/20 9:53 PM, Simon Marchi via Dwarf-Discuss wrote:

Hi,

The DW_AT_rnglists_base attribute is not listed in section 3.1.2 of DWARF5.pdf, 
which lists
the allowed attributes for DW_TAG_skeleton_unit.  However, in section 3.1.3, it 
says that the
split full compile unit (the one in the .dwo) inherits the value of 
DW_AT_rnglists_base from
the corresponding skeleton unit.  In Appendix A (attributes by tag), it says 
that
DW_TAG_skeleton_unit can have a DW_AT_rnglists_base.

So, is it simply an oversight in section 3.1.2?

Simon


Hi Simon --

My guess is that this is an oversight.  Can you submit an issue on the 
Public Comment page so that we can track it?

http://dwarfstd.org/Comment.php


--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?

[Michael Eager via Dwarf-Discuss]

On 3/23/20 3:58 PM, Cary Coutant via Dwarf-Discuss wrote:

I think that the description has become a bit less clear with the
addition of the Implicit Location Descriptions in Section 2.6.1.1.4,
which do compute values, rather than locations.  Perhaps these should
have been described in Section 2.5 as parts of a DWARF expression, not
as parts of a Location Description.


Strongly disagree. The whole point of an implicit location description
is to give a (pseudo/virtual) location to a value that has no
location. A DWARF *expression* has no use for these operators.


DW_OP_implicit_value and DW_OP_stack_value produce values (that is 
R-values), not locations.  I might be able to read 
DW_OP_implicit_pointer as providing a location; I'm not sure.


As I said, values and locations are muddled.  If you think that a 
variable which has been eliminated has a location which is described by 
a DW_OP_implicit_value, then we aren't working with the same definition 
of "location".


The problem is that the basic DWARF concept is that a variable has a 
location and that you can fetch its values from this location.  Thus, we 
expect to be able to evaluate a location description and dereference it 
to get a value.  Similarly, you can change a variable's value by 
modifying its location.  This dereference or modification may be a bit 
complicated if DW_OP_piece is involved, but the operation is symmetric. 
This I might call a "real" location description.


This doesn't work with any of the Implicit Location Descriptions, 
because there isn't any "there" there.  They don't result in locations; 
they give the values which would be found if the variable did exist.  So 
they implicitly perform the dereference operation.  But, in contrast to 
"real" location descriptions, the operation is not symmetric, you can't 
change the variable's value.

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?

[Michael Eager via Dwarf-Discuss]

On 3/23/20 6:28 AM, Robinson, Paul via Dwarf-Discuss wrote:

From: Dwarf-Discuss  On Behalf
Of Adrian Prantl via Dwarf-Discuss

On Mar 19, 2020, at 5:49 PM, Michael Eager via Dwarf-Discuss 
disc...@lists.dwarfstd.org> wrote:


My reading of sections 2.5 & 2.6 is that you cannot have a DW_OP_piece

in an DWARF expression.




I wonder if this is an intentional part of the design because of
ambiguity/correctness issues or is this just something that happens to
fall out of the way the text is worded? I can see how such a restriction
might simplify DWARF consumers, but it also seems like an arbitrary
restriction for which there may not be a technical reason.


My intuition (clearly I wasn't there at the time) is that this is like
a C expression being an rvalue (DWARF expression) or lvalue (location
description).  Values and locations aren't the same thing.


It is somewhat an L-value vs R-value issue.

You can craft a DWARF expression to extract a value (an R-value) from 
arbitrary memory locations or registers (for example, using DW_OP_and, 
DW_OP_sh?, etc.) and place it on the top of the stack.  A DW_OP_piece 
operator doesn't do this.  (There might be value in an operator which 
extracts a value from a composite location.)


A location (an L-value) which includes potentially multiple register or 
memory locations and multiple DW_OP_piece or DW_OP_bit_piece operations 
can't be evaluated by a simple stack-based expression interpreter.


The design is intentional, AFAIK, not accidental.

I think that the description has become a bit less clear with the 
addition of the Implicit Location Descriptions in Section 2.6.1.1.4, 
which do compute values, rather than locations.  Perhaps these should 
have been described in Section 2.5 as parts of a DWARF expression, not 
as parts of a Location Description.


The description (and implementation) of DWARF expressions and locations 
are somewhat muddled together.  This can be seen in the first sentence 
of Section 2.5:

   DWARF expressions describe how to compute a value or specify a
   location.
A clearer definition would specify that the DWARF expression only 
computes a value, and leaving what that value means (e.g., 
register/memory contents, arbitrary computation, memory address) to the 
context in which the expression is used.  A more precise definition of a 
location, especially a composite location, would help.


Part of this is historical, with the expression evaluation initially 
used to compute a memory address and then extended to accommodate 
composite locations and further extended to compute arbitrary values. 
These extensions were in divergent directions, affecting both location 
composition and value computation.  It would have been better if the two 
concepts were clearly distinguished.


--
Michael Eager

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Use of Location Description operations in DWARF Expressions?

[Michael Eager via Dwarf-Discuss]

On 3/19/20 9:30 AM, David Stenberg via Dwarf-Discuss wrote:

Hi!

This is something that has popped up in a number of LLVM patch reviews,
and is something that we would like to get some help with clarifying.

For DWARF[345], may a DWARF Expression (described in section 2.5)
contain any of the operations listed under the Location Descriptions
section (2.6)? For example, may a DW_AT_call_value in DWARF5, which
"is a DWARF expression", contain any of those operations
(e.g. a DW_OP_piece)?

DWARF5 section 2.5 specifies the following for the operations under
section 2.6:

"In addition to the general operations that are defined here, operations
  that are specific to location descriptions are defined in Section 2.6
  on page 38."

Reading section 2.5 and 2.6, I have interpreted the standard as if DWARF
Expressions and Location Descriptions are disparate things; Location
Descriptions may describe locations _using_ DWARF Expressions, but in
places where a DWARF Expression is expected, you may not have a Location
Description in its place. Is that correct?

Given the above quote, and if my interpretation of how DWARF Expressions
and Location Descriptions correlate is correct, I would assume that the
answer to this mail's initial question is no. Or am I overlooking
somethere here?


My reading of sections 2.5 & 2.6 is that you cannot have a DW_OP_piece 
in an DWARF expression.


A DWARF expression, when evaluated (as the result of evaluating a 
DW_AT_call_value), yields a value which is at the top of the stack.


A Composite Location Description, containing DW_OP_piece, as mentioned 
on page 42, "does not compute a value or store any result on the DWARF 
stack."


The DW_OP_reg* operations in a Location Description name a register, but 
do not modify the stack.  (See comment page 40.)


Implicit Location Descriptions may only appear in Location Descriptions. 
 The wording of the text says that the three operations specify a 
value, but do not say that this value is pushed on the stack.


--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] variable locations - safe use as lvalues

[Michael Eager via Dwarf-Discuss]

On 1/21/20 3:17 PM, Greg Clayton via Dwarf-Discuss wrote:




On Jan 21, 2020, at 2:58 PM, Frank Ch. Eigler via Dwarf-Discuss 
 wrote:

Hi -


While dwarfdump has 'check the DWARF' options available the
location list overlap test is not done at all. The -kl option suggests
it does loclist checking, but its checking is rather superficial.


Note that one should not present these overlaps as -errors- (because
they may be accurate), but rather as complications for lvalue usage.



Indeed. Warnings might be nice if the locations expressions are the same _and_ 
the types are different.

It would be very hard to figure out in a language agnostic way if two types are not the same 
("int" and a typedef to a "int" for example for C based languages).


A checker can walk down the type tree to find if the two types have the
same base types.

Common subexpression elimination could reuse the computed value even if
the source types were different.  (In C, typedef is an alias for a type,
not a different type.  C++ is marginally more restrictive.)

A debugger could alert the user that another variable also occupies the
same location and has been modified.  That might reduce the surprise
factor.  But this depends on neither of the complication 3 cases being
true, and there may be no way to confirm this.  This might give the user
an even stronger false impression that the new value is being used, when
it isn't.

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] variable locations - safe use as lvalues

[Michael Eager via Dwarf-Discuss]

On 1/20/20 6:21 PM, Frank Ch. Eigler via Dwarf-Discuss wrote:

Complication 2: The compiler reuses variable locations at the same PC. This
seems to be a compiler bug.


(Actually, this could be a valid optimization, e.g.:

int a = expression;
int b = expression;
   >
/* use/modify a */
/* use/modify b */

at that point, if $expression is a pure function, a compiler
could evaluate it once and reuse the value.  It could do this
by temporarily storing both a and b in the same register, and
only separating the variables afterwards.


Yes, where b is a copy of a, they can occupy the same location.  That 
does raise the question about what happens when the user instructs the 
debugger to change b, expecting that a will not be affected.



Complication 3a: That the value of a variable has been fetched for a
computation before the debugger modifies it.  This is more complicated. The
live range of the variable is accurate, but its value has been used before
the current PC.  DWARF does not include descriptions of data flow or
indicate where variables are fetched, so there is no information that a
debugger can use to assure that a modified value is actually used.


Yeah, and in the absence of dataflow metadata, tools like dyninst must
try to reverse-engineer the dataflow in order to perform binary
rewriting.  Is this something way out of forseeable dwarf scope?


I think that describing the data flow would be large.  Essentially, copy 
most of the IR data into DWARF.  If you have ideas about how to 
represent a compressed data flow graph, let us know.  There might only 
be a need for a limited subset.



There are a lot of issues with a debugger modifying a program while it is
running.  A debugger can make essentially unbounded changes to the program
state.  Some of these may work as expected, some may not, and it is unclear
how a debugger would be able to know the difference.


This is the key question: how can a tool know what is safe.  While the
trivial case of assuming every write is unsafe is not helpful :-), it
could be okay to have fairly conservative heuristics, known-partial
information, and rely on only clear signals to enable write
operations.


I can't think of any heuristic that would work, unless the debugger does 
an analysis of the generated code to find where variables are actively 
being used.  It also seems most likely that a user might want to modify 
variable exactly when they are being used, not where they are quiescent.



Anyway, it sounds like the next step is on us to analyze & prototype
in a compiler (gcc?).  I'd also appreciate authors of other dwarf
consumer and producer tools to mention whether they have considered
this area, so as to collect a census.



--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] variable locations - safe use as lvalues

[Michael Eager via Dwarf-Discuss]

On 1/20/20 2:20 PM, Frank Ch. Eigler via Dwarf-Discuss wrote:

Hi -

I have a question about variable location lists, but not their
encoding, the use they are suitable for.  The basic debugging scenario
is just reading variable values, for which this is fine, especially
when high-quality compilers emit exquisitely detailed data for their
optimized code.

But what about writes - as though one could edit the program to insert
an assignment, and resume?  A whole slew of complications come up:

- trying to modify a variable permanently, but the compiler only
   emitted -some- of its locations

- trying to modify a variable (and only one), but the compiler put two
   variables into the same location at that PC

- expressions using that value as input might have already started
   to be computed, so it may be too late to change it at the PC
   in question

- ... and undoubtedly other complications exist!


Interesting question.

Complication 1: That the compiler only emitted partial descriptions for 
the variable:  this seems to be a quality of implementation issue. 
There is nothing that a debugger can do if the compiler generates 
incomplete or misleading descriptions.  There is also no way that a 
debugger can ascertain that the compiler has generated a complete or 
accurate description.  Remedy: Fix the compiler.


Complication 2: The compiler reuses variable locations at the same PC. 
This seems to be a compiler bug.  While a location (e.g., a register) 
can be the location for multiple variables, the live ranges for these 
variables should not overlap.  The location lists for all variables 
should be disjoint.  Presumably, a debugger could check that location 
lists do not overlap.


For complication 3, an example might be
load  r1, =1
add   r1, var
PC ==>  store r1, var
There might be arbitrary additional instructions for multiple source 
statements interspersed.


This has has two variants:

Complication 3a: That the value of a variable has been fetched for a 
computation before the debugger modifies it.  This is more complicated. 
The live range of the variable is accurate, but its value has been used 
before the current PC.  DWARF does not include descriptions of data flow 
or indicate where variables are fetched, so there is no information that 
a debugger can use to assure that a modified value is actually used.


Complication 3b: That a variable's value may be modified after the 
debugger changes it at PC.  This is essentially a race condition.  Both 
the program and the debugger are updating the variable.  Last one wins.


> A debugger cannot currently be told that any particular variable
> location expression is safe to use as an lvalue, something roughly
> "exclusive, exhaustive, -O0-equivalent".  I believe most debuggers
> don't even handle the multiple-locations case for writes at all.  I
> don't know why - assume complications are rare?  or we have kind of
> papered over the problem?

There are a lot of issues with a debugger modifying a program while it 
is running.  A debugger can make essentially unbounded changes to the 
program state.  Some of these may work as expected, some may not, and it 
is unclear how a debugger would be able to know the difference.


There might be fewer problems modifying variables which are marked 
volatile.  But var in the example above could be volatile and the same 
issues would occur.


Are these complications rare?  Unclear.  I think that the great majority 
of debugger use is in displaying the value of variables, not in 
modifying them.


Have we papered over the problem?  Probably.  Debugging optimized code 
is difficult, even without trying to change the program state.


> As a DWARF standard level matter, descriptive rather than prescriptive
> as it is, what might be the minimum extension required to communicate
> lvalue-safety to a debugger?  A DW_OP_lvalue_safe assertive wrapper
> around a real expression?

Conceivably, location lists could be extended to include a flag to say 
that a variable is quiescent for a particular range of PC values and 
that a modification at that time would be persistent.  (A clear 
definition of quiescent would be needed.)


As Cary notes, a default or bounded location description might be used, 
but I don't believe that either implies that a variable is quiescent (or 
not) over the specified range.


--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] dwarf stack operator for byte swap.

[Michael Eager via Dwarf-Discuss]

Hi Chirag --

The DWARF Committee is currently on hiatus.  We will consider resuming 
meetings early next year.


On 12/16/19 4:30 AM, Chirag Patel wrote:

Hello Michael,

Thanks for opening the issue.
Can you kindly provide me with the details about what is the next step, 
till issue gets accepted/rejected or any modifications are needed?


Regards,

Chirag Patel
Software Engineer | Raincode Labs India
Tel: (+91) 080 41159811
Mob: (+91) 9049336744




*From:* Chirag Patel
*Sent:* 11 November 2019 13:07:19
*To:* Michael Eager ; Robinson, Paul 
; Ron Brender 

*Cc:* dwarf-discuss@lists.dwarfstd.org 
*Subject:* RE: [Dwarf-Discuss] dwarf stack operator for byte swap.
Hello Michael,

Thanks for the confirmation. Kindly inform me if anything needs to be 
updated from myside.


Regards,

Chirag Patel
Software Engineer | Raincode Labs India
Tel: (+91) 080 41159811
Mob: (+91) 9049336744
www.raincodelabs.com 


-Original Message-
From: Michael Eager 
Sent: 08 November 2019 20:04
To: Chirag Patel ; Robinson, Paul 
; Ron Brender 

Cc: dwarf-discuss@lists.dwarfstd.org
Subject: Re: [Dwarf-Discuss] dwarf stack operator for byte swap.

Hi Chirag --

Thanks for your submission.  It was received.

I'm redesigning the DWARF website, in part to address the problem that 
it receives a lot of spam submissions.  Your issue will be posted soon.


On 11/7/19 10:51 PM, Chirag Patel wrote:

Hi all,

I have sent a comment through http://dwarfstd.org/Comment.php

But below is the body of the comment “

Section 2.5.1.7, pg 37

DW_OP_byte_swap to Byte Swap the data on top of the dwarf stack.

==
=

Overview



For debugging binary with bi-endian marked dwarf DIEs and the some 
calculation


depending at runtime, the data needs to be loaded at runtime and needs 
to be


byte swapped. the depended variable DIE here is marked as big-endian 
and the


host is little-endian. The DW_OP_byte_swap will byte swap the raw data 
stored


in top dwarf stack entry.

…

0x0057:   DW_TAG_variable

      DW_AT_name  ("__gbloffset__")

      DW_AT_type  (0x01e5 "int")

      DW_AT_external  (true)

      DW_AT_decl_file ("…")

      DW_AT_decl_line (8)

      DW_AT_location  (DW_OP_addr 0) // pre linkage

      DW_AT_linkage_name  ("_gblsection__")

      DW_AT_endianity (DW_END_big)

0x0170:   DW_TAG_variable

      DW_AT_name  ("VAR1")

      DW_AT_type  (0x010b "fixed.dec.display.72")

      DW_AT_decl_file ("…")

      DW_AT_decl_line (10)

      DW_AT_location  (DW_OP_addr 0x0, DW_OP_call4 0x57, 
DW_OP_deref_size, 4,


DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit0, DW_OP_shl, DW_OP_and, 
DW_OP_lit24, DW_OP_shl, DW_OP_swap, DW_OP_dup, DW_OP_constu 0xff, 
DW_OP_lit8, DW_OP_shl, DW_OP_and, DW_OP_lit8, DW_OP_shl, DW_OP_swap, 
DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit16, DW_OP_shl, DW_OP_and, 
DW_OP_lit8, DW_OP_shr, DW_OP_swap, DW_OP_constu 0xff, DW_OP_lit24, 
DW_OP_shl, DW_OP_and, DW_OP_lit24, DW_OP_shr, DW_OP_swap, DW_OP_or, 
DW_OP_or, DW_OP_or, DW_OP_plus)


      DW_AT_linkage_name  ("VAR1")

In above snippet, the DW_OP_byte_swap will replace,

DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit0, DW_OP_shl, DW_OP_and, 
DW_OP_lit24, DW_OP_shl, DW_OP_swap, DW_OP_dup, DW_OP_constu 0xff, 
DW_OP_lit8, DW_OP_shl, DW_OP_and, DW_OP_lit8, DW_OP_shl, DW_OP_swap, 
DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit16, DW_OP_shl, DW_OP_and, 
DW_OP_lit8, DW_OP_shr, DW_OP_swap, DW_OP_constu 0xff, DW_OP_lit24, 
DW_OP_shl, DW_OP_and, DW_OP_lit24, DW_OP_shr, DW_OP_swap, DW_OP_or, 
DW_OP_or, DW_OP_or number of operations.


Proposed changes to DWARF

---

2.5.1.7 Special Operation

Addition

 DW_OP_byte_swap

     The DW_OP_byte_swap operation pops the top stack 
entry, byte swaps the value


     and pushes back the swapped value on the dwarf stack.

     e.g. so 0x12345678 will become 0x78563412, useful to 
change endianity of raw


     data.

---

“

i did not received any confirmation on my mail. How can I check if it 
was sent correctly?


Kindly inform me if anything more needs to be done from myside.

Regards,

**

*Chirag Patel*

Software Engineer | Raincode Labs India

*Tel*: (+91) 080 41159811

*Mob*: (+91) 9049336744

_www.raincodelabs.com _

linkedin-button 

*From:*Chirag Patel 
*Sent:* 29 October 2019 17:10
*To:* Michael Eager ; Robinson, Paul 
; Ron Brender 

*Cc:* dwarf-discuss@lists.dwarfstd.org
*Subject:* Re: [Dwarf-Discuss] dwarf stack operator for byte swap.

Hello,

Thank you all for prompt reply.

@Robinson, 

Re: [Dwarf-Discuss] dwarf stack operator for byte swap.

[Michael Eager via Dwarf-Discuss]

Hi Chirag --

Thanks for your submission.  It was received.

I'm redesigning the DWARF website, in part to address the problem that 
it receives a lot of spam submissions.  Your issue will be posted soon.


On 11/7/19 10:51 PM, Chirag Patel wrote:

Hi all,

I have sent a comment through http://dwarfstd.org/Comment.php

But below is the body of the comment “

Section 2.5.1.7, pg 37

DW_OP_byte_swap to Byte Swap the data on top of the dwarf stack.

===

Overview



For debugging binary with bi-endian marked dwarf DIEs and the some 
calculation


depending at runtime, the data needs to be loaded at runtime and needs 
to be


byte swapped. the depended variable DIE here is marked as big-endian and the

host is little-endian. The DW_OP_byte_swap will byte swap the raw data 
stored


in top dwarf stack entry.

…

0x0057:   DW_TAG_variable

     DW_AT_name  ("__gbloffset__")

     DW_AT_type  (0x01e5 "int")

     DW_AT_external  (true)

     DW_AT_decl_file ("…")

     DW_AT_decl_line (8)

     DW_AT_location  (DW_OP_addr 0) // pre linkage

     DW_AT_linkage_name  ("_gblsection__")

     DW_AT_endianity (DW_END_big)

0x0170:   DW_TAG_variable

     DW_AT_name  ("VAR1")

     DW_AT_type  (0x010b "fixed.dec.display.72")

     DW_AT_decl_file ("…")

     DW_AT_decl_line (10)

     DW_AT_location  (DW_OP_addr 0x0, DW_OP_call4 0x57, 
DW_OP_deref_size, 4,


DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit0, DW_OP_shl, DW_OP_and, 
DW_OP_lit24, DW_OP_shl, DW_OP_swap, DW_OP_dup, DW_OP_constu 0xff, 
DW_OP_lit8, DW_OP_shl, DW_OP_and, DW_OP_lit8, DW_OP_shl, DW_OP_swap, 
DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit16, DW_OP_shl, DW_OP_and, 
DW_OP_lit8, DW_OP_shr, DW_OP_swap, DW_OP_constu 0xff, DW_OP_lit24, 
DW_OP_shl, DW_OP_and, DW_OP_lit24, DW_OP_shr, DW_OP_swap, DW_OP_or, 
DW_OP_or, DW_OP_or, DW_OP_plus)


     DW_AT_linkage_name  ("VAR1")

In above snippet, the DW_OP_byte_swap will replace,

DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit0, DW_OP_shl, DW_OP_and, 
DW_OP_lit24, DW_OP_shl, DW_OP_swap, DW_OP_dup, DW_OP_constu 0xff, 
DW_OP_lit8, DW_OP_shl, DW_OP_and, DW_OP_lit8, DW_OP_shl, DW_OP_swap, 
DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit16, DW_OP_shl, DW_OP_and, 
DW_OP_lit8, DW_OP_shr, DW_OP_swap, DW_OP_constu 0xff, DW_OP_lit24, 
DW_OP_shl, DW_OP_and, DW_OP_lit24, DW_OP_shr, DW_OP_swap, DW_OP_or, 
DW_OP_or, DW_OP_or number of operations.


Proposed changes to DWARF

---

2.5.1.7 Special Operation

Addition

 DW_OP_byte_swap

    The DW_OP_byte_swap operation pops the top stack entry, 
byte swaps the value


    and pushes back the swapped value on the dwarf stack.

    e.g. so 0x12345678 will become 0x78563412, useful to 
change endianity of raw


    data.

---

“

i did not received any confirmation on my mail. How can I check if it 
was sent correctly?


Kindly inform me if anything more needs to be done from myside.

Regards,

**

*Chirag Patel*

Software Engineer | Raincode Labs India

*Tel*: (+91) 080 41159811

*Mob*: (+91) 9049336744

_www.raincodelabs.com _

linkedin-button 

*From:*Chirag Patel 
*Sent:* 29 October 2019 17:10
*To:* Michael Eager ; Robinson, Paul 
; Ron Brender 

*Cc:* dwarf-discuss@lists.dwarfstd.org
*Subject:* Re: [Dwarf-Discuss] dwarf stack operator for byte swap.

Hello,

Thank you all for prompt reply.

@Robinson, Paul ,

Thanks for the shorter list of operators, but as Michael has suggested, 
i have added a vendor specific operator for that in llvm/lldb(fork of 
our branch anyways).


the operator, pops the stack entry and byte reverses the value and 
pushes it back on the stack.


@Ron Brender 

The operator that i was suggesting, pops the top of the stack, reverses 
the bytes and pushes it on the stack(like neg operator does for 
negation).(on second thought the byte_rev would be a better name)


About the other cases you suggested, i sure hope others can help to zero 
in for perfect


design to cover wide range.

@Michael Eager 

Thanks, i have tried the same for our fork of llvm/lldb branch and it 
seems to be working well(for our case :). 
https://gitlab.phidani.be/Chirag.Patel


Thank you all for the helpful comments. i will open a dwarf enhancement 
request soon.


Best Regards.

*Chirag Patel*

Software Engineer*| *Raincode Labs India

Tel: (+91) 080 41159811

Mob: (+91) 9049336744



_

_

Re: [Dwarf-Discuss] dwarf stack operator for byte swap.

[Michael Eager via Dwarf-Discuss]

Hi Chirag --

A byte-swap operator would be a reasonable addition to the DWARF 
interpreter.


In addition to writing a proposal as Paul suggests, one option I would 
recommend you consider is to create a user-defined operation to perform 
this byte-swap operation and give it a value in the range between 
DW_OP_lo_user and DW_OP_hi_user.  Of course, this user-defined would 
need to be implemented not only in the producer (i.e., compiler) but in 
any consumers (i.e., debugger).


When a new version of the DWARF Standard is released, this operation 
would be assigned a new value.


On 10/28/19 6:53 AM, Robinson, Paul via Dwarf-Discuss wrote:

Hello Chirag,

Regarding a byte-swap operation, it seems that you have a reasonable 
use-case on a bi-endian machine.  Feel free to request a new operator on 
the “public comments” page at http://dwarfstd.org/Comment.php


Note that a byte-swap operator would swap all bytes in the top-of-stack 
value, which on your 64-bit machine would of course be a 64-bit value.  
As you want a 32-bit swapped value, you would still need to do a shift 
afterward, but even so, “DW_OP_byte_swap DW_OP_const1u 32 DW_OP_shr” 
would be considerably shorter than what you have to do now.


Of course a new operator would be introduced in a new DWARF revision, 
which is likely to be years away.  In the meantime let me suggest a 
shorter expression for doing the byte-swap operation.  The book 
“Hacker’s Delight” shows a straightforward 32-bit byte swap with masks 
no wider than 16 bits, as follows:


    x = (x << 24) | ((x & 0xff00) << 8) | ((x >> 8) & 
0xff00) | (x >> 24);


Your 64-bit machine will of course use 64-bit values on the expression 
stack, so to keep the result “32-bit clean” we want to do one additional 
mask:


    x = ((x & 0xff) << 24) | ((x & 0xff00) << 8) | ((x >> 8) 
& 0xff00) | (x >> 24);


Translating this into a DWARF expression, I get the following:

    DW_OP_dup, DW_OP_const1u 0xff, DW_OP_and, DW_OP_lit24, 
DW_OP_shl, DW_OP_swap, DW_OP_dup, DW_OP_const2u 0xff00, DW_OP_and, 
DW_OP_lit8, DW_OP_shl, DW_OP_swap, DW_OP_dup, DW_OP_lit8, DW_OP_shr, 
DW_OP_const2u 0xff00, DW_OP_and, DW_OP_swap, DW_OP_lit24, DW_OP_shr, 
DW_OP_or, DW_OP_or, DW_OP_or


I hope this is helpful to you.

--paulr

*From:* Dwarf-Discuss  *On 
Behalf Of *Chirag Patel via Dwarf-Discuss

*Sent:* Monday, October 28, 2019 12:47 AM
*To:* dwarf-discuss@lists.dwarfstd.org
*Subject:* [Dwarf-Discuss] dwarf stack operator for byte swap.

Hello Dwarf experts.

I am currently working trying to encode dwarf of binaries with having 
bi-endian variables marked with DW_AT_endianity attribute.


The location calculation for some  variable depends on other variable 
with different endianity, also the value of this other variable is known 
at runtime.


At the moment I am using location list to calculate the correct location 
of first variable and list of dwarf operators to reverse the endianity 
of variable “__gbloffset__” in below case (I only needed lower 32 bits 
on 64 bit machine).


0x01e5: DW_TAG_base_type

  DW_AT_byte_size  (0x04)

   DW_AT_encoding  (DW_ATE_signed)

     DW_AT_name  ("int")

     DW_AT_endianity (DW_END_big)

…

0x0057:   DW_TAG_variable

     DW_AT_name  ("__gbloffset__")

     DW_AT_type  (0x01e5 "int")

     DW_AT_external  (true)

     DW_AT_decl_file ("…")

     DW_AT_decl_line (8)

     DW_AT_location  (DW_OP_addr 0) // pre linkage

     DW_AT_linkage_name  ("_gblsection__")

0x0170:   DW_TAG_variable

     DW_AT_name  ("VAR1")

     DW_AT_type  (0x010b "fixed.dec.display.72")

     DW_AT_decl_file ("…")

     DW_AT_decl_line (10)

     DW_AT_location  (DW_OP_addr 0x0, DW_OP_call4 0x57, 
DW_OP_deref_size, 4,


DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit0, DW_OP_shl, DW_OP_and, 
DW_OP_lit24, DW_OP_shl, DW_OP_swap, DW_OP_dup, DW_OP_constu 0xff, 
DW_OP_lit8, DW_OP_shl, DW_OP_and, DW_OP_lit8, DW_OP_shl, DW_OP_swap, 
DW_OP_dup, DW_OP_constu 0xff, DW_OP_lit16, DW_OP_shl, DW_OP_and, 
DW_OP_lit8, DW_OP_shr, DW_OP_swap, DW_OP_constu 0xff, DW_OP_lit24, 
DW_OP_shl, DW_OP_and, DW_OP_lit24, DW_OP_shr, DW_OP_swap, DW_OP_or, 
DW_OP_or, DW_OP_or, DW_OP_plus)


     DW_AT_linkage_name  ("VAR1")

In above snippet of dwarf dump, I am using yellow highlighted list of 
operators to swap the bytes.


I think there should be a support for DW_OP_byte_swap simple operator to 
accomplice this simple task. Does this idea looks like it can be useful? 
Is there any specific reason why dwarf spec does not have it or I am 
missing something subtle.


I hope I conveyed the idea properly, apologies in advanced as English is 
not my first language.


**

*Thanks and regards,*

**

*Chirag Patel*

Software Engineer | Raincode Labs India

*Tel*: (+91) 080 41159811

Re: [Dwarf-Discuss] dsymutil: "could not find referenced DIE" followed by a segmentation fault and other newbie questions

[Michael Eager via Dwarf-Discuss]

On 12/08/2018 06:24 AM, Gil Moses via Dwarf-Discuss wrote:

Hi,

Building with Xcode 7, once in a while I get the following warnings from the 
dsymutil tool (a few dozens):
"could not find referenced DIE"
Followed be a segmentation fault.

Adding the verbosity flag, I got detailed information about the DIEs that had 
the error, e.g.:
===
while processing 
/p4client/ProAudio/dev_main/ProAudio/XcodeBuildProducts/Debug/libWaveShell-Common.a(GraphicStream_Utils.o):
warning: could not find referenced DIE
 in DIE:

0x0001415e:   DW_TAG_imported_declaration [99]
 DW_AT_decl_file [DW_FORM_data1]
("/Applications/Xcode7.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_types/_time_t.h")
 DW_AT_decl_line [DW_FORM_data2](20047)
 DW_AT_import [DW_FORM_ref4](cu + 0x4c4f5254 => 
{0x4c4f5254})


How do I go about understanding the error, what caused it and how to solve it?
BTW, the lib size being built is around 350MB. Could there be a size issue 
causing this seg fault?

While I'm here, where could I download the full source code of dsymutil? All I 
found was links to separate files 
(https://opensource.apple.com/source/clang/clang-700.0.72/src/tools/dsymutil/)

Thanks,
Gil Moses.


Hi Gil --

This is not really a question about DWARF.  This looks like a bug
in Clang.  You would get more help with this by sending your question to
the LLVM/Clang mailing list.

--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Location list entries for caller-saved registers at time of call

[Michael Eager via Dwarf-Discuss]

On 12/07/2018 08:12 AM, Jakub Jelinek wrote:

On Fri, Dec 07, 2018 at 07:57:23AM -0800, Michael Eager wrote:

On 12/07/2018 04:54 AM, Jakub Jelinek wrote:

On Fri, Dec 07, 2018 at 12:36:39PM +, David Stenberg via Dwarf-Discuss 
wrote:

For calls, we need to distinguish the locations that are valid in the caller
on the call instruction before the call instruction has been executed, then
locations that are valid while inside of the call and finally locations that
are valid after the call has returned.


But the call instruction is atomic.  There are not distinct PC locations
within an individual call instruction.


The instruction itself is, but the invocation of the called procedure is
not.


So?  The return address doesn't slowly creep through the call
instruction as the called procedure executes.


I know what the PC is before the call, I know what the
return address is in the called routine, and I know what the PC is
after the return.  None of these addresses is in the middle of the call.

Why not generate the label as the next address following the call?


Because there is some other code there and some other locations might be
valid at that point, but not during the call.  E.g. something could live in
the register holding return value from the function, which won't be there
until the function returns.  The labels can be:
.L0:
   whatever1
.L1:
   call foo
.L2:
   whatever2
.L3:

and in .debug_loc etc., I can provide say one location description for the
range .L0 to .L1 (i.e. for instructions before the call
instruction, another one e.g. for .L1 to .L2-1, valid on the call
instruction, but not inside of the foo call, another one from .L2-1 to .L2,
valid after the call foo instruction is done but before the call returned
(i.e. inside of the foo call or whatever it calls) and finally .L2 to .L3
range which covers the instructions after the call.


The reason that the loclist is [start, end) is so that you do not need
to pretend that there is a valid .L2-1 PC value.  There is no valid PC
range of [.L1, .L2-1) or [.L2-1, .L2).  When inside the called
procedure, the return address is .L2, NOT .L2-1.

When generating a loclist for the calling function, you don't need to be
concerned about the called procedure.  All you need to do is list the
valid range of PC values in that function.


The debug info consumers usually subtract one from the return address with
the exception of signal frames so that they locate something in the middle
of the call instruction rather than whatever is after it (there could be
e.g. a completely different function be there already, or completely
unrelated code e.g. for calls that never return).


As mentioned before, producers should generate DWARF which describes the
code generated, and not attempt to compensate for what it believes a
consumer is doing.

None of the reasons you give seem to call for generating an invalid PC
in the loclist.   In the case of a call which is the last instruction
in a function. the loclist would have an end address which is after the
function.  This is OK, and the address is explicitly excluded from the
range.

--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] debug_names - what should go in ?

[Michael Eager via Dwarf-Discuss]

On 04/10/2018 08:33 AM, Pavel Labath via Dwarf-Discuss wrote:

I believe it makes sense to include both of these things in the index
(including the implicitly-named imported declarations), however I would
also like to stick to the specification as much as possible. I know the
spec gives implementors freedom to include extra information in the index,
but I don't want to do that too much, as that would complicate matters for
consumers which need to support multiple producers, some of which may have
a stricter implementation of the spec.


This is a new feature in DWARF v5 with a newly written description.
It's possible that some details may have been overlooked or that
the wording in the description doesn't fully or unambiguously describe
the feature.

If you believe that the two TAGs should be included, do so and let
us know the results.

Please submit a comment at http://dwarfstd.org/Issues.php which
describes the situation and your proposed changes to the standard.

--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org