From david.stenberg@ericsson.com  Thu Dec  6 12:40:02 2018
From: david.stenberg@ericsson.com (David Stenberg)
Date: Thu, 6 Dec 2018 12:40:02 +0000
Subject: [Dwarf-Discuss] Location list entries for caller-saved registers at
 time of call
Message-ID: <1544100002.30451.11.camel@ericsson.com>

Hi!

When GDB and LLDB perform virtual unwinding, they subtract one byte
from the return addresses of the outer frames. This is for example
necessary when unwinding from a non-returning call that is placed last
in the function, as the return address then can point to a different
function. I assume that this is also necessary to get the variables
that were in scope at the time of the call, and the right location
expressions for the variables, etc.

As far as I have understood it, GCC utilizes this fact for location
list entries that are expressed in caller-saved registers, by
subtracting one from the (exclusive) ending address of the entries.
This means that variables in outer frames that are located in caller-
saved registers will be printed out as <optimized out> by GDB.

I have not been able to find anything in the DWARF standard that
describes this. Is this something that is defined by standard, or is it
established praxis between GCC and GDB? If the latter, do you know of
other producers and consumers that behave like this?

The reason why I ask this is because Clang/LLVM at the moment ends
location list entries expressed in caller-saved registers at the first
instruction after the call. This means that variables in outer frames
using such location list entries will incorrectly be evaluated using
the inner-most frame's register values when debugging in GDB.

(As a side note, as far as I have understood it, LLDB has fallback
knowledge of the ABI, so caller-saved registers will be considered
unavailable in outer frames, meaning that such location list entries
are not an issue when combining Clang/LLVM and LLDB.)

Best regards,
David


From arnez@linux.ibm.com  Thu Dec  6 15:32:58 2018
From: arnez@linux.ibm.com (Andreas Arnez)
Date: Thu, 06 Dec 2018 16:32:58 +0100
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <1544100002.30451.11.camel@ericsson.com> (David Stenberg via
 Dwarf-Discuss's message of "Thu, 6 Dec 2018 12:40:02 +0000")
References: <1544100002.30451.11.camel@ericsson.com>
Message-ID: <m3efauzn4l.fsf@oc0404454431.ibm.com>

On Thu, Dec 06 2018, David Stenberg via Dwarf-Discuss wrote:

> [...] variables in outer frames using such location list entries will
> incorrectly be evaluated using the inner-most frame's register values
> when debugging in GDB.

If GDB uses caller-saved register values from the inner-most frame in
outer frames, then this is a bug.  Note that this could also be caused
by bad CFI.

--
Andreas



From david.stenberg@ericsson.com  Thu Dec  6 15:49:56 2018
From: david.stenberg@ericsson.com (David Stenberg)
Date: Thu, 6 Dec 2018 15:49:56 +0000
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <m3efauzn4l.fsf@oc0404454431.ibm.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <m3efauzn4l.fsf@oc0404454431.ibm.com>
Message-ID: <1544111396.30451.25.camel@ericsson.com>

On tor, 2018-12-06 at 16:32 +0100, Andreas Arnez via Dwarf-Discuss
wrote:
> If GDB uses caller-saved register values from the inner-most frame in
> outer frames, then this is a bug.? Note that this could also be
> caused
> by bad CFI.

Hmm, right. I'm not very familiar with the design philosophy of GDB,
but as far as I have understood it they prefer to rely on producer to?
emit such information. In the LLVM bug report [0] I wrote for this I
mentioned using DW_CFA_undefined for caller-saved registers, or at
least for those that it knows are clobbered.

Neither GCC nor Clang emits CFI for caller-saved registers at the
moment. I have not been successful in finding out why, but my
(uneducated) guess is that, maybe at least one of the reasons, is
debug info size concerns?

[0] https://bugs.llvm.org/show_bug.cgi?id=39752

Best regards,
David


From eager@eagercon.com  Thu Dec  6 17:19:20 2018
From: eager@eagercon.com (Michael Eager)
Date: Thu, 6 Dec 2018 09:19:20 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <1544100002.30451.11.camel@ericsson.com>
References: <1544100002.30451.11.camel@ericsson.com>
Message-ID: <ff5f37a7-6b9d-a8fb-e6f1-7ca24ffabeba@eagercon.com>

On 12/06/2018 04:40 AM, David Stenberg via Dwarf-Discuss wrote:
> Hi!
> 
> When GDB and LLDB perform virtual unwinding, they subtract one byte
> from the return addresses of the outer frames. This is for example
> necessary when unwinding from a non-returning call that is placed last
> in the function, as the return address then can point to a different
> function. I assume that this is also necessary to get the variables
> that were in scope at the time of the call, and the right location
> expressions for the variables, etc.

As you mention, GDB is trying to insure that the computed return address
is within the scope of the function, so that the function will be
identified correctly.

> As far as I have understood it, GCC utilizes this fact for location
> list entries that are expressed in caller-saved registers, by
> subtracting one from the (exclusive) ending address of the entries.

Similarly, the ending address of a LocList entry could be one beyond
the end of a function, if the address is of a variable allocated at
the end.  Subtracting one insures that the correct function is
identified.

> This means that variables in outer frames that are located in caller-
> saved registers will be printed out as <optimized out> by GDB
Why?

> I have not been able to find anything in the DWARF standard that
> describes this. Is this something that is defined by standard, or is it
> established praxis between GCC and GDB? If the latter, do you know of
> other producers and consumers that behave like this?

No, this is not part of the DWARF specification.

This isn't any shared knowledge between GCC and GDB.  Subtracting
one from the end address to insure that the address is within the
function is simply to accommodate the occasional situation where the
call is the last instruction in the function.

> The reason why I ask this is because Clang/LLVM at the moment ends
> location list entries expressed in caller-saved registers at the first
> instruction after the call. This means that variables in outer frames
> using such location list entries will incorrectly be evaluated using
> the inner-most frame's register values when debugging in GDB.

The DWARF definition of a LocList entry (Sec. 2.6.2) says that the
     "[t]he starting address is the lowest address of the address range
     over which the location is valid. The ending address is the address
     of the first location past the highest address of the address
     range."

GDB frame handling is recursive and can be confusing.  In most cases,
GDB uses the next frame pointer as a handle for evaluating variables
in the current frame.  That does not mean that the evaluation is
using the inner-frame registers.

(From your other email):

Hmm, right. I'm not very familiar with the design philosophy of GDB,
but as far as I have understood it they prefer to rely on producer to
emit such information. In the LLVM bug report [0] I wrote for this I
mentioned using DW_CFA_undefined for caller-saved registers, or at
least for those that it knows are clobbered.

Why?

Neither GCC nor Clang emits CFI for caller-saved registers at the
moment. I have not been successful in finding out why, but my
(uneducated) guess is that, maybe at least one of the reasons, is
debug info size concerns?

Exactly.   Some (most?) producers do not encode ABI requirements in
the CFI, since this would be duplicated in every CFI entry.

DWARF philosophy is not to duplicate information which is defined
by the ABI or other architecture definitions.

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


From ron.brender@gmail.com  Thu Dec  6 20:36:34 2018
From: ron.brender@gmail.com (Ron Brender)
Date: Thu, 6 Dec 2018 15:36:34 -0500
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <1544100002.30451.11.camel@ericsson.com>
References: <1544100002.30451.11.camel@ericsson.com>
Message-ID: <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>

Comments are inline...

On Thu, Dec 6, 2018 at 7:40 AM David Stenberg via Dwarf-Discuss <
dwarf-discuss at lists.dwarfstd.org> wrote:

> Hi!
>
> When GDB and LLDB perform virtual unwinding, they subtract one byte
> from the return addresses of the outer frames. This is for example
> necessary when unwinding from a non-returning call that is placed last
> in the function, as the return address then can point to a different
> function. I assume that this is also necessary to get the variables
> that were in scope at the time of the call, and the right location
> expressions for the variables, etc.
>

Yes, I am aware of this practice--indeed, it is mentioned in Section 6.4.4
of both the
V4 and V5 standards.

Another perfectly good solution is for the compiler to assure that the
return PC is always in the
right scope to begin with. All it takes is to include a (never executed)
NOP following any non-returning
CALL at the last address of the routine.Such calls are not common, plus
many environments align
the beginning of (any subsequent) functions anyway so padding bytes are
likely to be available. As a
result, such "extra" bytes are not going to be a space issue.

As far as I have understood it, GCC utilizes this fact for location
> list entries that are expressed in caller-saved registers, by
> subtracting one from the (exclusive) ending address of the entries.
> This means that variables in outer frames that are located in caller-
> saved registers will be printed out as <optimized out> by GDB.
>

Here you lose me. Once you do what is described in your first paragraph,
there seems no need
to do anything special about location lists at all. You seem to be saying
that GCC somehow
mis-represents those ranges for some reason, but I don't follow how or why
or under what
circumstances?

I have not been able to find anything in the DWARF standard that
> describes this. Is this something that is defined by standard, or is it
> established praxis between GCC and GDB? If the latter, do you know of
> other producers and consumers that behave like this.
>

As mentioned, see Section 6.4.4 of both the V4 and V5 standards.

GCC (or other producers) has nothing to do with it. GCC (or other
producers) should just describe
the program as it exists. Only the debugger needs to know how to avoid this
quirk of no-return
optimization.


> The reason why I ask this is because Clang/LLVM at the moment ends
> location list entries expressed in caller-saved registers at the first
> instruction after the call. This means that variables in outer frames
> using such location list entries will incorrectly be evaluated using
> the inner-most frame's register values when debugging in GDB.
>

But if GDB does what you say in the first paragraph, this will not be a
problem.
I don't follow...

>
> (As a side note, as far as I have understood it, LLDB has fallback
> knowledge of the ABI, so caller-saved registers will be considered
> unavailable in outer frames, meaning that such location list entries
> are not an issue when combining Clang/LLVM and LLDB.)
>
> Best regards,
> David
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20181206/eca63579/attachment.html>


From ccoutant@gmail.com  Thu Dec  6 20:47:22 2018
From: ccoutant@gmail.com (Cary Coutant)
Date: Thu, 6 Dec 2018 12:47:22 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
Message-ID: <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>

> Another perfectly good solution is for the compiler to assure that the return PC is always in the
> right scope to begin with. All it takes is to include a (never executed) NOP following any non-returning
> CALL at the last address of the routine.Such calls are not common, plus many environments align
> the beginning of (any subsequent) functions anyway so padding bytes are likely to be available. As a
> result, such "extra" bytes are not going to be a space issue.

In fact, the PA-RISC and Itanium calling conventions specifically require this.

-cary


From eager@eagerm.com  Fri Dec  7 00:55:39 2018
From: eager@eagerm.com (Michael Eager)
Date: Thu, 6 Dec 2018 16:55:39 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
Message-ID: <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>

On 12/06/2018 12:47 PM, Cary Coutant via Dwarf-Discuss wrote:
>> Another perfectly good solution is for the compiler to assure that the return PC is always in the
>> right scope to begin with. All it takes is to include a (never executed) NOP following any non-returning
>> CALL at the last address of the routine.Such calls are not common, plus many environments align
>> the beginning of (any subsequent) functions anyway so padding bytes are likely to be available. As a
>> result, such "extra" bytes are not going to be a space issue.
> 
> In fact, the PA-RISC and Itanium calling conventions specifically require this.

Not all ABIs do this.  Many allow the end of one function to be
immediately followed by the start of the next function.

Subtracting one from the return address is a trivial way to insure
that the address is within the calling function and not in the
next function.  And it works on all architectures.

In any case, this is the way that GDB has handled return addresses
for n >= 2 decades.  Whatever the OP's issue is, this is not related.

-- 
Michael Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306


From ccoutant@gmail.com  Fri Dec  7 01:47:51 2018
From: ccoutant@gmail.com (Cary Coutant)
Date: Thu, 6 Dec 2018 17:47:51 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
Message-ID: <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>

> > In fact, the PA-RISC and Itanium calling conventions specifically require this.
>
> Not all ABIs do this.  Many allow the end of one function to be
> immediately followed by the start of the next function.

We're talking about the narrow case of a function that ends with a
no-return call. In all other situations, of course it's fine to have
one function immediately follow the previous.

This also applies to no-return calls in the interior of a function,
where the next instruction might be part of a code region with
different unwind descriptors.

> Subtracting one from the return address is a trivial way to insure
> that the address is within the calling function and not in the
> next function.  And it works on all architectures.

It's not exactly trivial: it's not always correct to do this (e.g.,
when unwinding from a signal handler), and the unwinder needs to know
how to recognize those kinds of frames. For PA-RISC and Itanium, we
elected to make the rule simple: the pc value, whether it derives from
a return pointer or a sigcontext, will always get you the correct
unwind information.

But we're getting sidetracked from the OP's question: Does GCC in fact
subtract one from the upper bound of a location list entry for a
variable contained in a caller-saved register? I can think of no
reason why it should do this. If the compiled code does something like
this:

    A: promote variable X into caller-save register R
       ...
       call f
    B: ...
       spill register R back to X
    C: ...

The location list entry for x should show it live in register R in the
range [A..C). The call should not interrupt the range.

It sounds like David has an example where the range list entry shows x
in register R in the range [A..B-1), then presumably again for [B..C),
leaving [B-1..B) uncovered. That would be a bug, in my opinion.

David, can you show us an example?

-cary

-cary


From david.stenberg@ericsson.com  Fri Dec  7 12:36:39 2018
From: david.stenberg@ericsson.com (David Stenberg)
Date: Fri, 7 Dec 2018 12:36:39 +0000
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
Message-ID: <1544186198.30451.97.camel@ericsson.com>

On tor, 2018-12-06 at 17:47 -0800, Cary Coutant via Dwarf-Discuss
wrote:
> But we're getting sidetracked from the OP's question: Does GCC in
> fact
> subtract one from the upper bound of a location list entry for a
> variable contained in a caller-saved register? I can think of no
> reason why it should do this. If the compiled code does something
> like
> this:
> 
> ??? A: promote variable X into caller-save register R
> ?????? ...
> ?????? call f
> ??? B: ...
> ?????? spill register R back to X
> ??? C: ...
> 
> The location list entry for x should show it live in register R in
> the
> range [A..C). The call should not interrupt the range.
> 
> It sounds like David has an example where the range list entry shows
> x
> in register R in the range [A..B-1), then presumably again for
> [B..C),
> leaving [B-1..B) uncovered. That would be a bug, in my opinion.
> 
> David, can you show us an example?

In the following example I used GCC 7.3.0, and compiled the below
listed C code using `-O1 -gstrict-dwarf -gdwarf-5'.

? extern int get();
? extern void set(int);
??
? int main() {
? ? int local = get();
? ? set(local);
? ? local = 123;
? ? return local;
? }

This produces the following location list for `local':

? ? 0000000c 000000000000000e 0000000000000014 (DW_OP_reg0 (rax))
????00000011 0000000000000015 000000000000001f (DW_OP_const1u: 123; ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DW_OP_stack_value)

? ?9:???e8 00 00 00 00??????????callq??e <main+0xe>
???e:???89 c7???????????????????mov????%eax,%edi
? 10:???e8 00 00 00 00??????????callq??15 <main+0x15>
? 15:???b8 7b 00 00 00??????????mov????$0x7b,%eax

As seen, there is a one-byte gap at the end of the call instruction to
set().

As far as I have understood it, GCC emits a location list like this
because it knows that the producer will subtract one from the return
address when doing virtual unwinding. In this way, GDB will print the
variable as "<optimized out>" when unwinding from set() to main(), even
though it does not have knowledge of whether or not RAX is caller-
saved.

If we instead use Clang, there is no gap in the location list for the
same code:

? ? [0x0000000000000008, 0x000000000000000f): DW_OP_reg0 RAX
????[0x000000000000000f, 0x0000000000000016): DW_OP_consts +123,
??????????????????????????????????????????????DW_OP_stack_value)

? ?3:???e8 00 00 00 00??????????callq??8 <main+0x8>
???8:???89 c7???????????????????mov????%eax,%edi
???a:???e8 00 00 00 00??????????callq??f <main+0xf>
???f:???b8 7b 00 00 00??????????mov????$0x7b,%eax

When debugging the Clang-built binary in GDB, when unwinding from set()
to main(), `local' will be evaluated using the value RAX has in set(),
rather then being printed as "<optimized out>".

Best regards,
David


From jakub@redhat.com  Fri Dec  7 12:54:37 2018
From: jakub@redhat.com (Jakub Jelinek)
Date: Fri, 7 Dec 2018 13:54:37 +0100
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <1544186198.30451.97.camel@ericsson.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
Message-ID: <20181207125437.GH12380@tucnak>

On Fri, Dec 07, 2018 at 12:36:39PM +0000, 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.
The 3 can differ, before the call instruction has been executed the
locations can include registers clobbered by the call, during the call they
can't, as the call could have clobbered them already.  Call-saved registers
aren't a problem, there is unwind info in the callee how to restore that and
the debugger can unwind to the caller.  As GCC generally doesn't track the
length of the call instruction, it uses that end of call instruction - 1
as the label somewhere in the middle of the call instruction, so at the
start of the call instruction can be some locations, during the call other
set and right after the call another set.

	Jakub


From eager@eagerm.com  Fri Dec  7 15:56:30 2018
From: eager@eagerm.com (Michael Eager)
Date: Fri, 7 Dec 2018 07:56:30 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <1544186198.30451.97.camel@ericsson.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
Message-ID: <5957dce7-f400-cdb5-4abe-adec1fa33d4a@eagerm.com>

On 12/07/2018 04:36 AM, David Stenberg wrote:
> On tor, 2018-12-06 at 17:47 -0800, Cary Coutant via Dwarf-Discuss
> wrote:
>> But we're getting sidetracked from the OP's question: Does GCC in
>> fact
>> subtract one from the upper bound of a location list entry for a
>> variable contained in a caller-saved register? I can think of no
>> reason why it should do this. If the compiled code does something
>> like
>> this:
>>
>>  ??? A: promote variable X into caller-save register R
>>  ?????? ...
>>  ?????? call f
>>  ??? B: ...
>>  ?????? spill register R back to X
>>  ??? C: ...
>>
>> The location list entry for x should show it live in register R in
>> the
>> range [A..C). The call should not interrupt the range.
>>
>> It sounds like David has an example where the range list entry shows
>> x
>> in register R in the range [A..B-1), then presumably again for
>> [B..C),
>> leaving [B-1..B) uncovered. That would be a bug, in my opinion.
>>
>> David, can you show us an example?
> 
> In the following example I used GCC 7.3.0, and compiled the below
> listed C code using `-O1 -gstrict-dwarf -gdwarf-5'.
> 
>  ? extern int get();
>  ? extern void set(int);
>    
>  ? int main() {
>  ? ? int local = get();
>  ? ? set(local);
>  ? ? local = 123;
>  ? ? return local;
>  ? }
> 
> This produces the following location list for `local':
> 
>  ? ? 0000000c 000000000000000e 0000000000000014 (DW_OP_reg0 (rax))
>  ????00000011 0000000000000015 000000000000001f (DW_OP_const1u: 123;
>  ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DW_OP_stack_value)
> 
>  ? ?9:???e8 00 00 00 00??????????callq??e <main+0xe>
>  ???e:???89 c7???????????????????mov????%eax,%edi
>  ? 10:???e8 00 00 00 00??????????callq??15 <main+0x15>
>  ? 15:???b8 7b 00 00 00??????????mov????$0x7b,%eax
> 
> As seen, there is a one-byte gap at the end of the call instruction to
> set().
> 
> As far as I have understood it, GCC emits a location list like this
> because it knows that the producer will subtract one from the return
> address when doing virtual unwinding. In this way, GDB will print the
> variable as "<optimized out>" when unwinding from set() to main(), even
> though it does not have knowledge of whether or not RAX is caller-
> saved.

Speaking generally, a producer should describe the code generated and
nothing more.  It should not attempt to anticipate or compensate for the
behavior of a consumer.  That leads to bugs in the consumer causing
bugs in the producer.  The reverse is true, naturally, but consumers
often have to adapt to odd (or buggy) producers.

It looks to me that the loclist should be [0xe, 0x15), not as generated.
When the PC is anywhere in the range from 0xe up to but not including
0x15, rax is in reg0.

> If we instead use Clang, there is no gap in the location list for the
> same code:
> 
>  ? ? [0x0000000000000008, 0x000000000000000f): DW_OP_reg0 RAX
>  ????[0x000000000000000f, 0x0000000000000016): DW_OP_consts +123,
>  ??????????????????????????????????????????????DW_OP_stack_value)
> 
>  ? ?3:???e8 00 00 00 00??????????callq??8 <main+0x8>
>  ???8:???89 c7???????????????????mov????%eax,%edi
>  ???a:???e8 00 00 00 00??????????callq??f <main+0xf>
>  ???f:???b8 7b 00 00 00??????????mov????$0x7b,%eax
> 
> When debugging the Clang-built binary in GDB, when unwinding from set()
> to main(), `local' will be evaluated using the value RAX has in set(),
> rather then being printed as "<optimized out>".
> 
> Best regards,
> David
> 

-- 
Michael Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306


From eager@eagerm.com  Fri Dec  7 15:57:23 2018
From: eager@eagerm.com (Michael Eager)
Date: Fri, 7 Dec 2018 07:57:23 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <20181207125437.GH12380@tucnak>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com> <20181207125437.GH12380@tucnak>
Message-ID: <f421f803-f5ba-20db-aee4-990d97bd8d79@eagerm.com>

On 12/07/2018 04:54 AM, Jakub Jelinek wrote:
> On Fri, Dec 07, 2018 at 12:36:39PM +0000, 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 3 can differ, before the call instruction has been executed the
> locations can include registers clobbered by the call, during the call they
> can't, as the call could have clobbered them already.  Call-saved registers
> aren't a problem, there is unwind info in the callee how to restore that and
> the debugger can unwind to the caller.  As GCC generally doesn't track the
> length of the call instruction, it uses that end of call instruction - 1
> as the label somewhere in the middle of the call instruction, so at the
> start of the call instruction can be some locations, during the call other
> set and right after the call another set.

What does this mean?  If GCC doesn't know the length of the call
instruction, how can it generate a label of the end - 1?

There is no valid PC address in the middle of a call instruction (as
noted above).  What does a label in the middle of an instruction mean?

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?

-- 
Michael Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306


From jakub@redhat.com  Fri Dec  7 16:12:45 2018
From: jakub@redhat.com (Jakub Jelinek)
Date: Fri, 7 Dec 2018 17:12:45 +0100
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <f421f803-f5ba-20db-aee4-990d97bd8d79@eagerm.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
 <20181207125437.GH12380@tucnak>
 <f421f803-f5ba-20db-aee4-990d97bd8d79@eagerm.com>
Message-ID: <20181207161245.GM12380@tucnak>

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 +0000, 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.

> 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 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).

	Jakub


From ccoutant@gmail.com  Fri Dec  7 16:26:35 2018
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 7 Dec 2018 08:26:35 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <1544186198.30451.97.camel@ericsson.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
Message-ID: <CAJimCsE=KGWJoWOWVMCd0wx5OWuY=b-OFtOErsP6Fo+H=23uEg@mail.gmail.com>

> In the following example I used GCC 7.3.0, and compiled the below
> listed C code using `-O1 -gstrict-dwarf -gdwarf-5'.
>
>   extern int get();
>   extern void set(int);
>
>   int main() {
>     int local = get();
>     set(local);
>     local = 123;
>     return local;
>   }
>
> This produces the following location list for `local':
>
>     0000000c 000000000000000e 0000000000000014 (DW_OP_reg0 (rax))
>     00000011 0000000000000015 000000000000001f (DW_OP_const1u: 123;
>                                                 DW_OP_stack_value)
>
>    9:   e8 00 00 00 00          callq  e <main+0xe>
>    e:   89 c7                   mov    %eax,%edi
>   10:   e8 00 00 00 00          callq  15 <main+0x15>
>   15:   b8 7b 00 00 00          mov    $0x7b,%eax
>
> As seen, there is a one-byte gap at the end of the call instruction to
> set().

This example shows local in %eax, which is a caller-save (i.e.,
scratch) register. GCC is right to show that the value is unknown upon
return from the call, because set() can clobber that register.

Try changing your code so that you use the value of local after the
call to set() -- say, make it "local += 123" -- and see the
difference. My copy of GCC moves local to %ebx, which is a caller-save
register, and the location list shows it live in that register all the
way through the call and return.

> If we instead use Clang, there is no gap in the location list for the
> same code:
>
>     [0x0000000000000008, 0x000000000000000f): DW_OP_reg0 RAX
>     [0x000000000000000f, 0x0000000000000016): DW_OP_consts +123,
>                                               DW_OP_stack_value)
>
>    3:   e8 00 00 00 00          callq  8 <main+0x8>
>    8:   89 c7                   mov    %eax,%edi
>    a:   e8 00 00 00 00          callq  f <main+0xf>
>    f:   b8 7b 00 00 00          mov    $0x7b,%eax
>
> When debugging the Clang-built binary in GDB, when unwinding from set()
> to main(), `local' will be evaluated using the value RAX has in set(),
> rather then being printed as "<optimized out>".

I think clang is wrong here. Because the call can clobber the
register, the compiler should not claim that the value is live upon
return.

-cary


From eager@eagerm.com  Fri Dec  7 16:28:06 2018
From: eager@eagerm.com (Michael Eager)
Date: Fri, 7 Dec 2018 08:28:06 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <20181207161245.GM12380@tucnak>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com> <20181207125437.GH12380@tucnak>
 <f421f803-f5ba-20db-aee4-990d97bd8d79@eagerm.com>
 <20181207161245.GM12380@tucnak>
Message-ID: <638bcd6a-f297-2730-65b7-56f05d59ad89@eagerm.com>

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 +0000, 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 Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306


From eager@eagerm.com  Fri Dec  7 16:32:46 2018
From: eager@eagerm.com (Michael Eager)
Date: Fri, 7 Dec 2018 08:32:46 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <CAJimCsE=KGWJoWOWVMCd0wx5OWuY=b-OFtOErsP6Fo+H=23uEg@mail.gmail.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
 <CAJimCsE=KGWJoWOWVMCd0wx5OWuY=b-OFtOErsP6Fo+H=23uEg@mail.gmail.com>
Message-ID: <94da2bc8-63ca-fe69-168d-707e215cae94@eagerm.com>

On 12/07/2018 08:26 AM, Cary Coutant wrote:
>> In the following example I used GCC 7.3.0, and compiled the below
>> listed C code using `-O1 -gstrict-dwarf -gdwarf-5'.
>>
>>    extern int get();
>>    extern void set(int);
>>
>>    int main() {
>>      int local = get();
>>      set(local);
>>      local = 123;
>>      return local;
>>    }
>>
>> This produces the following location list for `local':
>>
>>      0000000c 000000000000000e 0000000000000014 (DW_OP_reg0 (rax))
>>      00000011 0000000000000015 000000000000001f (DW_OP_const1u: 123;
>>                                                  DW_OP_stack_value)
>>
>>     9:   e8 00 00 00 00          callq  e <main+0xe>
>>     e:   89 c7                   mov    %eax,%edi
>>    10:   e8 00 00 00 00          callq  15 <main+0x15>
>>    15:   b8 7b 00 00 00          mov    $0x7b,%eax
>>
>> As seen, there is a one-byte gap at the end of the call instruction to
>> set().
> 
> This example shows local in %eax, which is a caller-save (i.e.,
> scratch) register. GCC is right to show that the value is unknown upon
> return from the call, because set() can clobber that register.
> 
> Try changing your code so that you use the value of local after the
> call to set() -- say, make it "local += 123" -- and see the
> difference. My copy of GCC moves local to %ebx, which is a caller-save
> register, and the location list shows it live in that register all the
> way through the call and return.
> 
>> If we instead use Clang, there is no gap in the location list for the
>> same code:
>>
>>      [0x0000000000000008, 0x000000000000000f): DW_OP_reg0 RAX
>>      [0x000000000000000f, 0x0000000000000016): DW_OP_consts +123,
>>                                                DW_OP_stack_value)
>>
>>     3:   e8 00 00 00 00          callq  8 <main+0x8>
>>     8:   89 c7                   mov    %eax,%edi
>>     a:   e8 00 00 00 00          callq  f <main+0xf>
>>     f:   b8 7b 00 00 00          mov    $0x7b,%eax
>>
>> When debugging the Clang-built binary in GDB, when unwinding from set()
>> to main(), `local' will be evaluated using the value RAX has in set(),
>> rather then being printed as "<optimized out>".
> 
> I think clang is wrong here. Because the call can clobber the
> register, the compiler should not claim that the value is live upon
> return.

I think clang is correct.

As I read the loclists, from 0x8 up to but not including 0xf, the
value is in reg0, from 0xf (after the call) up to but not including
0x16, the value is on the stack.

I don't see that this describes the value as live (in a register)
after the call, at PC = 0xf.

-- 
Michael Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306


From ccoutant@gmail.com  Fri Dec  7 16:33:54 2018
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 7 Dec 2018 08:33:54 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <CAJimCsE=KGWJoWOWVMCd0wx5OWuY=b-OFtOErsP6Fo+H=23uEg@mail.gmail.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
 <CAJimCsE=KGWJoWOWVMCd0wx5OWuY=b-OFtOErsP6Fo+H=23uEg@mail.gmail.com>
Message-ID: <CAJimCsH-W6vRbJsvHu=ca5E4rPSiVELE2PzuRRBUmjtkKAaS5w@mail.gmail.com>

> This example shows local in %eax, which is a caller-save (i.e.,
> scratch) register. GCC is right to show that the value is unknown upon
> return from the call, because set() can clobber that register.

Sorry, typo -- %eax is a *callee-save* register.

-cary


From jakub@redhat.com  Fri Dec  7 16:37:41 2018
From: jakub@redhat.com (Jakub Jelinek)
Date: Fri, 7 Dec 2018 17:37:41 +0100
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <638bcd6a-f297-2730-65b7-56f05d59ad89@eagerm.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
 <20181207125437.GH12380@tucnak>
 <f421f803-f5ba-20db-aee4-990d97bd8d79@eagerm.com>
 <20181207161245.GM12380@tucnak>
 <638bcd6a-f297-2730-65b7-56f05d59ad89@eagerm.com>
Message-ID: <20181207163741.GO12380@tucnak>

On Fri, Dec 07, 2018 at 08:28:06AM -0800, Michael Eager wrote:
> > 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.

I don't see a restriction in the DWARF standard that would say that all
ranges must be boundaries of instructions.  And, if I limit to just that,
I can only have ranges .L0-.L1, instructions before the call but not on the
call instruction itself, .L1-.L2, the call instruction and .L2-.L3 which
would be inside of the call + at the start of the instruction after it.
And those two need to be differentiated, otherwise the compiler would need
to emit a nop after every call, which an optimizing compiler is not willing
to do.  As I said, all the consumers that aren't horribly broken subtract
one, because there is no guarantee of the nop instructions after the calls.

	Jakub


From ccoutant@gmail.com  Fri Dec  7 16:38:33 2018
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 7 Dec 2018 08:38:33 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <638bcd6a-f297-2730-65b7-56f05d59ad89@eagerm.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com> <20181207125437.GH12380@tucnak>
 <f421f803-f5ba-20db-aee4-990d97bd8d79@eagerm.com>
 <20181207161245.GM12380@tucnak>
 <638bcd6a-f297-2730-65b7-56f05d59ad89@eagerm.com>
Message-ID: <CAJimCsFgcJ6JiTBC3jCR+daqo-nQDPawcXafDkoNqRZiyTpc4g@mail.gmail.com>

> >>> 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.

Jakub is correct. It's not that the return address creeps slowly
through the call instruction -- it's that there are three distinct
phases in the call:

1: before the call (pc is at the call instruction)
2: during the call (pc is in the called function, and rp points to the
instruction after the call)
3: after the call (pc is at the instruction after the call)

Before the call (1), the value is still live in %eax, so the range
should include the address of the call instruction.

During the call (2), the value is unknown, because %eax is
callee-save. As postulated, GCC is aware that unwinders will subtract
1 from the rp, so it knows that it can exclude this phase from the
range list entry by subtracting one from the address of the next
instruction. (It could just as easily used the address of the call
instruction + 1.)

After the call (3), the value is still unknown. Setting the end of the
range to the address of the instruction following the call would have
covered this, but not the time during the call.

-cary


From ccoutant@gmail.com  Fri Dec  7 16:45:47 2018
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 7 Dec 2018 08:45:47 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <94da2bc8-63ca-fe69-168d-707e215cae94@eagerm.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
 <CAJimCsE=KGWJoWOWVMCd0wx5OWuY=b-OFtOErsP6Fo+H=23uEg@mail.gmail.com>
 <94da2bc8-63ca-fe69-168d-707e215cae94@eagerm.com>
Message-ID: <CAJimCsG7ATgTNtUoqEw8C2j=aWkLGrxDiPxHi7KBY4OW49Oipw@mail.gmail.com>

> I think clang is correct.
>
> As I read the loclists, from 0x8 up to but not including 0xf, the
> value is in reg0, from 0xf (after the call) up to but not including
> 0x16, the value is on the stack.
>
> I don't see that this describes the value as live (in a register)
> after the call, at PC = 0xf.

But *during* the call, when the unwinder will use a PC value of 0xe to
query the range list, it will think the value is still live in %eax,
which is not true. If the unwinder did not subtract 1 from the PC
value, it would get the right answer, but since it does subtract 1,
GCC needs to adjust the end of the range list entry.

-cary


From ccoutant@gmail.com  Fri Dec  7 16:58:42 2018
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 7 Dec 2018 08:58:42 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <5957dce7-f400-cdb5-4abe-adec1fa33d4a@eagerm.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
 <5957dce7-f400-cdb5-4abe-adec1fa33d4a@eagerm.com>
Message-ID: <CAJimCsG9TWeY3+QhaAUzgEBdi+auq6uR8TV7BDE-ffNAiBZRkQ@mail.gmail.com>

> Speaking generally, a producer should describe the code generated and
> nothing more.  It should not attempt to anticipate or compensate for the
> behavior of a consumer.  That leads to bugs in the consumer causing
> bugs in the producer.  The reverse is true, naturally, but consumers
> often have to adapt to odd (or buggy) producers.

And that's another reason why on PA-RISC and Itanium we have the rule
that the unwind info for the PC of the instruction following the call
must be accurate. With that rule, we do not have to anticipate or
compensate for the consumer. One hack always begets another hack. (Of
course, if some debuggers were to subtract 1 despite that rule, we
would have to either compensate or declare them buggy.)

Jakub complains that "the compiler would need to emit a nop after
every call, which an optimizing compiler is not willing to do." We're
not talking about *every* call, just the rare case of a no-return
call.

-cary


From jakub@redhat.com  Fri Dec  7 17:06:31 2018
From: jakub@redhat.com (Jakub Jelinek)
Date: Fri, 7 Dec 2018 18:06:31 +0100
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <CAJimCsG9TWeY3+QhaAUzgEBdi+auq6uR8TV7BDE-ffNAiBZRkQ@mail.gmail.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
 <5957dce7-f400-cdb5-4abe-adec1fa33d4a@eagerm.com>
 <CAJimCsG9TWeY3+QhaAUzgEBdi+auq6uR8TV7BDE-ffNAiBZRkQ@mail.gmail.com>
Message-ID: <20181207170631.GQ12380@tucnak>

On Fri, Dec 07, 2018 at 08:58:42AM -0800, Cary Coutant via Dwarf-Discuss wrote:
> And that's another reason why on PA-RISC and Itanium we have the rule
> that the unwind info for the PC of the instruction following the call
> must be accurate. With that rule, we do not have to anticipate or
> compensate for the consumer. One hack always begets another hack. (Of
> course, if some debuggers were to subtract 1 despite that rule, we
> would have to either compensate or declare them buggy.)
> 
> Jakub complains that "the compiler would need to emit a nop after
> every call, which an optimizing compiler is not willing to do." We're
> not talking about *every* call, just the rare case of a no-return
> call.

They aren't that rare, and even if they would, that is still not enough.
For proper debug info one needs to differentiate between the context inside
of the call and the context right after the call, while in the %eax case
that has been discussed it makes no difference, in others it does.

Consider:
void bar (void);
void baz (int);
int
foo (void)
{
  int a = 6;
  bar ();
  {
    long a = 5;
    baz (10);
  }
  return 10;
}
If you don't subtract one during unwinding and during the bar call look at
foo's frame, then it would appear as if you are already at the baz call with
the inner a variable in scope, but that shouldn't be in scope yet, and if
user asks for value of a, he should see that 6 and its type should be int,
not long.

	Jakub


From eager@eagerm.com  Fri Dec  7 17:10:37 2018
From: eager@eagerm.com (Michael Eager)
Date: Fri, 7 Dec 2018 09:10:37 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <CAJimCsFgcJ6JiTBC3jCR+daqo-nQDPawcXafDkoNqRZiyTpc4g@mail.gmail.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com> <20181207125437.GH12380@tucnak>
 <f421f803-f5ba-20db-aee4-990d97bd8d79@eagerm.com>
 <20181207161245.GM12380@tucnak>
 <638bcd6a-f297-2730-65b7-56f05d59ad89@eagerm.com>
 <CAJimCsFgcJ6JiTBC3jCR+daqo-nQDPawcXafDkoNqRZiyTpc4g@mail.gmail.com>
Message-ID: <938efe57-8066-de02-712c-4b1a0a75957a@eagerm.com>

On 12/07/2018 08:38 AM, Cary Coutant 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.
> 
> Jakub is correct. It's not that the return address creeps slowly
> through the call instruction -- it's that there are three distinct
> phases in the call:
> 
> 1: before the call (pc is at the call instruction)
> 2: during the call (pc is in the called function, and rp points to the
> instruction after the call)
> 3: after the call (pc is at the instruction after the call)
> 
> Before the call (1), the value is still live in %eax, so the range
> should include the address of the call instruction.
> 
> During the call (2), the value is unknown, because %eax is
> callee-save. As postulated, GCC is aware that unwinders will subtract
> 1 from the rp, so it knows that it can exclude this phase from the
> range list entry by subtracting one from the address of the next
> instruction. (It could just as easily used the address of the call
> instruction + 1.)

I think I see the difference in our viewpoints.

I believe that when the consumer (GDB in this case) unwinds the stack,
the PC should be at the return location.  If it evaluates the loclist
with this value, it will get the correct result.

GDB subtracts one to insure that the return PC is within the calling
function, so that it will find the debug data for the correct function.
That's fine.  It then uses this modified PC value to search the loclist,
which is (IMO) a bug.

> After the call (3), the value is still unknown. Setting the end of the
> range to the address of the instruction following the call would have
> covered this, but not the time during the call.
> 
> -cary
> 
> 

-- 
Michael Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306


From ccoutant@gmail.com  Fri Dec  7 17:30:27 2018
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 7 Dec 2018 09:30:27 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <20181207170631.GQ12380@tucnak>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
 <5957dce7-f400-cdb5-4abe-adec1fa33d4a@eagerm.com>
 <CAJimCsG9TWeY3+QhaAUzgEBdi+auq6uR8TV7BDE-ffNAiBZRkQ@mail.gmail.com>
 <20181207170631.GQ12380@tucnak>
Message-ID: <CAJimCsG_RueKnwGAt7oVSFJ9kZ_CGkQN0BmGZQZnc1DzNw3E0A@mail.gmail.com>

> > Jakub complains that "the compiler would need to emit a nop after
> > every call, which an optimizing compiler is not willing to do." We're
> > not talking about *every* call, just the rare case of a no-return
> > call.
>
> They aren't that rare, and even if they would, that is still not enough.
> For proper debug info one needs to differentiate between the context inside
> of the call and the context right after the call, while in the %eax case
> that has been discussed it makes no difference, in others it does.
>
> Consider:
> void bar (void);
> void baz (int);
> int
> foo (void)
> {
>   int a = 6;
>   bar ();
>   {
>     long a = 5;
>     baz (10);
>   }
>   return 10;
> }
> If you don't subtract one during unwinding and during the bar call look at
> foo's frame, then it would appear as if you are already at the baz call with
> the inner a variable in scope, but that shouldn't be in scope yet, and if
> user asks for value of a, he should see that 6 and its type should be int,
> not long.

Yes, you're right -- that's a good point. That suggests that perhaps
we should do something more explicit to distinguish between "during a
call" and "after a call". What happens on architectures where the call
instruction is just one addressable unit long? For example, a
word-addressed architecture, or Itanium where some toolchains encode
the slot number as (0, 1, 2) in the low-order bits of the PC?

-cary


From ccoutant@gmail.com  Fri Dec  7 17:58:22 2018
From: ccoutant@gmail.com (Cary Coutant)
Date: Fri, 7 Dec 2018 09:58:22 -0800
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <CAJimCsH-W6vRbJsvHu=ca5E4rPSiVELE2PzuRRBUmjtkKAaS5w@mail.gmail.com>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
 <CAJimCsE=KGWJoWOWVMCd0wx5OWuY=b-OFtOErsP6Fo+H=23uEg@mail.gmail.com>
 <CAJimCsH-W6vRbJsvHu=ca5E4rPSiVELE2PzuRRBUmjtkKAaS5w@mail.gmail.com>
Message-ID: <CAJimCsFBsQDtB5MRG44GTs-hw1DtnukbMOO-dksGSyqcfLp+XQ@mail.gmail.com>

> > This example shows local in %eax, which is a caller-save (i.e.,
> > scratch) register. GCC is right to show that the value is unknown upon
> > return from the call, because set() can clobber that register.
>
> Sorry, typo -- %eax is a *callee-save* register.

Argh! No, I was right the first time. %eax is a caller-save (scratch) register.

Here was the typo:

> Try changing your code so that you use the value of local after the
> call to set() -- say, make it "local += 123" -- and see the
> difference. My copy of GCC moves local to %ebx, which is a caller-save
> register, and the location list shows it live in that register all the
> way through the call and return.

%ebx is a *callee-save* (preserved) register.

I always have to think twice and I still get callee-save and
caller-save backwards! That's why I prefer the terms "scratch" and
"preserved".

Sorry for the confusion. David correctly said it was a caller-save
register in his original mail, and if I hadn't thought "callee-save"
instead, I'd have been able to answer his question straight away.

-cary


From gil.moses@outlook.com  Sat Dec  8 14:24:59 2018
From: gil.moses@outlook.com (Gil Moses)
Date: Sat, 8 Dec 2018 14:24:59 +0000
Subject: [Dwarf-Discuss] dsymutil: "could not find referenced DIE" followed
 by a segmentation fault and other newbie questions
In-Reply-To: <BN8PR10MB3667C37F78042E038AB1C7D9F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
References: <BN8PR10MB3667C37F78042E038AB1C7D9F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
Message-ID: <BN8PR10MB366770B09750E88056803D97F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>

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.


From eager@eagerm.com  Sat Dec  8 15:07:47 2018
From: eager@eagerm.com (Michael Eager)
Date: Sat, 8 Dec 2018 07:07:47 -0800
Subject: [Dwarf-Discuss] dsymutil: "could not find referenced DIE"
 followed by a segmentation fault and other newbie questions
In-Reply-To: <BN8PR10MB366770B09750E88056803D97F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
References: <BN8PR10MB3667C37F78042E038AB1C7D9F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
 <BN8PR10MB366770B09750E88056803D97F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
Message-ID: <02f1a32c-3de2-2b71-edda-10d1a86cb14b@eagerm.com>

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 Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306


From andrew.cagney@gmail.com  Sun Dec  9 03:26:18 2018
From: andrew.cagney@gmail.com (Andrew Cagney)
Date: Sat, 8 Dec 2018 22:26:18 -0500
Subject: [Dwarf-Discuss] Location list entries for caller-saved
 registers at time of call
In-Reply-To: <20181207170631.GQ12380@tucnak>
References: <1544100002.30451.11.camel@ericsson.com>
 <CANSbVTiyVdqPnAXEnfZ+WTWBmng6TayBL7x78CkNLyJX6SakOw@mail.gmail.com>
 <CAJimCsHXCtjGpd57U39NBV0Lp4MW7vO=KTXiZEP_fAVk5C5Gtw@mail.gmail.com>
 <4cb0c139-702a-fb7b-18d5-21df05dd4217@eagerm.com>
 <CAJimCsFaYRCQFhTt1ZeN9BcGD0fUE3YEe_K1=-+OLR7RDuBCOQ@mail.gmail.com>
 <1544186198.30451.97.camel@ericsson.com>
 <5957dce7-f400-cdb5-4abe-adec1fa33d4a@eagerm.com>
 <CAJimCsG9TWeY3+QhaAUzgEBdi+auq6uR8TV7BDE-ffNAiBZRkQ@mail.gmail.com>
 <20181207170631.GQ12380@tucnak>
Message-ID: <CAJeAr6tv6p1ukCBYsqvDZkwsJ-=8mMjM3=NoassXt6PNRkkC8g@mail.gmail.com>

On Fri, 7 Dec 2018 at 16:56, Jakub Jelinek via Dwarf-Discuss
<dwarf-discuss at lists.dwarfstd.org> wrote:
>
> On Fri, Dec 07, 2018 at 08:58:42AM -0800, Cary Coutant via Dwarf-Discuss wrote:
> > And that's another reason why on PA-RISC and Itanium we have the rule
> > that the unwind info for the PC of the instruction following the call
> > must be accurate. With that rule, we do not have to anticipate or
> > compensate for the consumer. One hack always begets another hack. (Of
> > course, if some debuggers were to subtract 1 despite that rule, we
> > would have to either compensate or declare them buggy.)
> >
> > Jakub complains that "the compiler would need to emit a nop after
> > every call, which an optimizing compiler is not willing to do." We're
> > not talking about *every* call, just the rare case of a no-return
> > call.
>
> They aren't that rare, and even if they would, that is still not enough.
> For proper debug info one needs to differentiate between the context inside
> of the call and the context right after the call, while in the %eax case
> that has been discussed it makes no difference, in others it does.
>
> Consider:
> void bar (void);
> void baz (int);
> int
> foo (void)
> {
>   int a = 6;
>   bar ();
>   {
>     long a = 5;
>     baz (10);
>   }
>   return 10;
> }
> If you don't subtract one during unwinding and during the bar call look at
> foo's frame, then it would appear as if you are already at the baz call with
> the inner a variable in scope, but that shouldn't be in scope yet, and if
> user asks for value of a, he should see that 6 and its type should be int,
> not long.

To expand on CFI.

If one isn't subtracted then unwinding may not even work.  Compilers,
while generating information to unwind thw 'PC' to the 'return
address', generate unwind information to restore the stack structure
to _before_ the call.  This is because the SP immediately before and
immediately after the function call can be different.

For instance, on a VAX, the return instruction discards parameters on
the stack that were pushed before CALLS was executed something like:

  push parameters
  # SP includes parameter list
  callS foo() -- pushes # parameters along with other stuff
  # on return 'parameters' are gone
 nop

https://www.computer.org/csdl/proceedings/afips/1978/5086/00/50860967.pdf

I've always wondered about generating zero-length location
descriptions (which currently are illegal) to handle these cases.  It
would address Cary's 1-instruction call problem.

Andrew


From gil.moses@outlook.com  Sun Dec  9 15:27:15 2018
From: gil.moses@outlook.com (Gil Moses)
Date: Sun, 9 Dec 2018 15:27:15 +0000
Subject: [Dwarf-Discuss] dsymutil: "could not find referenced DIE"
 followed by a segmentation fault and other newbie questions
In-Reply-To: <02f1a32c-3de2-2b71-edda-10d1a86cb14b@eagerm.com>
References: <BN8PR10MB3667C37F78042E038AB1C7D9F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
 <BN8PR10MB366770B09750E88056803D97F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
 <02f1a32c-3de2-2b71-edda-10d1a86cb14b@eagerm.com>
Message-ID: <BN8PR10MB36678A9EBB866C2D600E9F4CF7A40@BN8PR10MB3667.namprd10.prod.outlook.com>

Hi Michael,

Although it might be a bug in Clang, I'd like to get a grip on the DWARF side of it - i.e. understanding the error and tracking down the root cause.
Also, since dsymutil is an open source project util that generates DWARF files, I was hoping someone would know where to download the project. Then, I might be able to debug my problem.
Thanks,
Gil.


From gil.moses@outlook.com  Sun Dec  9 15:31:22 2018
From: gil.moses@outlook.com (Gil Moses)
Date: Sun, 9 Dec 2018 15:31:22 +0000
Subject: [Dwarf-Discuss] dsymutil: "could not find referenced DIE"
 followed by a segmentation fault and other newbie questions
In-Reply-To: <BN8PR10MB36678A9EBB866C2D600E9F4CF7A40@BN8PR10MB3667.namprd10.prod.outlook.com>
References: <BN8PR10MB3667C37F78042E038AB1C7D9F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
 <BN8PR10MB366770B09750E88056803D97F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
 <02f1a32c-3de2-2b71-edda-10d1a86cb14b@eagerm.com>
 <BN8PR10MB36678A9EBB866C2D600E9F4CF7A40@BN8PR10MB3667.namprd10.prod.outlook.com>
Message-ID: <BN8PR10MB3667F96C4C45803D8CE5E721F7A40@BN8PR10MB3667.namprd10.prod.outlook.com>

BTW, following your advice I also posted in two other lists - CLang and LLVM.
Gil.


From eager@eagerm.com  Sun Dec  9 15:55:16 2018
From: eager@eagerm.com (Michael Eager)
Date: Sun, 9 Dec 2018 07:55:16 -0800
Subject: [Dwarf-Discuss] dsymutil: "could not find referenced DIE"
 followed by a segmentation fault and other newbie questions
In-Reply-To: <BN8PR10MB36678A9EBB866C2D600E9F4CF7A40@BN8PR10MB3667.namprd10.prod.outlook.com>
References: <BN8PR10MB3667C37F78042E038AB1C7D9F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
 <BN8PR10MB366770B09750E88056803D97F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
 <02f1a32c-3de2-2b71-edda-10d1a86cb14b@eagerm.com>
 <BN8PR10MB36678A9EBB866C2D600E9F4CF7A40@BN8PR10MB3667.namprd10.prod.outlook.com>
Message-ID: <9792633e-f0db-3255-61d7-d4131560b019@eagerm.com>

On 12/09/2018 07:27 AM, Gil Moses via Dwarf-Discuss wrote:
> Hi Michael,
> 
> Although it might be a bug in Clang, I'd like to get a grip on the DWARF side of it - i.e. understanding the error and tracking down the root cause.
> Also, since dsymutil is an open source project util that generates DWARF files, I was hoping someone would know where to download the project. Then, I might be able to debug my problem.

DW_TAG_imported_declaration is the DWARF representation of "using" in 
C++ (and similar constructs in other languages).  It says to include the 
DWARF DIE (and its children) which are pointed to by the DW_AT_import 
attribute (an offset in the current compilation unit) into the current 
scope.

Appendix D.3 in the DWARF Version 5 spec has an example.

In the error you received, dsymutil says that it could not find the DIE 
that the DW_AT_import referenced.  You can look at the DWARF debug info 
(using readelf or dwarfdump) and see what is at offset 0x4c4f5254.  If 
that is not a DIE, then the DWARF generated by clang is incorrect.  If 
it is a DIE, then dysmutil is confused.

-- 
Michael Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306


From ccoutant@gmail.com  Sun Dec  9 22:22:47 2018
From: ccoutant@gmail.com (Cary Coutant)
Date: Sun, 9 Dec 2018 14:22:47 -0800
Subject: [Dwarf-Discuss] dsymutil: "could not find referenced DIE"
 followed by a segmentation fault and other newbie questions
In-Reply-To: <BN8PR10MB366770B09750E88056803D97F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
References: <BN8PR10MB3667C37F78042E038AB1C7D9F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
 <BN8PR10MB366770B09750E88056803D97F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
Message-ID: <CAJimCsFxkg0DRdCE1WFN7ECQAzEWjbKi_TWp8DVfmgNyxGt9wQ@mail.gmail.com>

> 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?

The offset it gives, 0x4c4f5254, is much too large for a file in the
350MB range, so this is clearly bogus. The value is ASCII for "LORT"
-- it looks like an ASCII string has made its way into your DWARF info
somehow.

-cary


From aprantl@apple.com  Mon Dec 10 17:55:56 2018
From: aprantl@apple.com (Adrian Prantl)
Date: Mon, 10 Dec 2018 09:55:56 -0800
Subject: [Dwarf-Discuss] dsymutil: "could not find referenced DIE"
 followed by a segmentation fault and other newbie questions
In-Reply-To: <BN8PR10MB366770B09750E88056803D97F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
References: <BN8PR10MB3667C37F78042E038AB1C7D9F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
 <BN8PR10MB366770B09750E88056803D97F7AB0@BN8PR10MB3667.namprd10.prod.outlook.com>
Message-ID: <4EF537DC-3C9A-45DB-8B96-F5E32FB089F0@apple.com>



> On Dec 8, 2018, at 6:24 AM, Gil Moses via Dwarf-Discuss <dwarf-discuss at lists.dwarfstd.org> 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?

If you have questions about Apple-specific versions of the various LLVM tools, the best way to get in contact is to file a bugreport on https://bugreport.apple.com/.

The version of dsymutil that you are using (700) is quite old. Is using a newer version from a more recent Xcode an option for you?

> 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/)

Dsymutil is part of the LLVM project, if you want to build it from source, you'll need to download LLVM and compile the "dsymutil" target. The https://opensource.apple.com/source/clang/clang-700.0.72/src directory you mentioned should contains the entire LLVM project. Instructions for building it can be found here: http://llvm.org/docs/GettingStarted.html.

That said, I would recommend trying a more recent version of dsymutil first.

-- adrian


From davea42@linuxmail.org  Mon Dec 10 22:20:26 2018
From: davea42@linuxmail.org (David Anderson)
Date: Mon, 10 Dec 2018 14:20:26 -0800
Subject: [Dwarf-Discuss] dwarfdump libdwarf on mach-o and PE object file
 DWARF.
Message-ID: <8d80701a-1d6b-3a8c-3868-ef22a9dd9834@linuxmail.org>

dwarfdump/libdwarf can work on mach-o dsym objects and
on gcc-generated DWARF in PE objects (as well as Elf objects), but
one has to get the latest from sourceforge. See
 https://www.prevanders.net/dwarf.html

None of the released libdwarf '*.tar.gz' versions have such support
at this time.

Building libdwarf/dwarfdump under mingw on Windows the gcc CFLAGS
 -DHAVE_WINDOWS_H -DHAVE_NONSTANDARD_PRINTF_64_FORMAT
 -fno-dwarf2-cfi-asm
seem to be essential (and have at least worked for one person).

David Anderson


