> > 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
17 matches
Mail list logo
