On Fri, 7 Dec 2018 at 16:56, Jakub Jelinek via Dwarf-Discuss
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
> > 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 tim
> > 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
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 cal
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
> compe
> 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 hav
> 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 =
> >>> 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
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 in
> 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
__
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
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 v
> 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 th
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 c
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
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 regi
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
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 s
> > 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.
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 th
> 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
> envi
Comments are inline...
On Thu, Dec 6, 2018 at 7:40 AM David Stenberg via Dwarf-Discuss <
dwarf-discuss@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 unw
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 th
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
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
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
26 matches
Mail list logo
