Discrepancy in debugging information for the value pointed to by the global pointer variable "shared_ptr" in binaries compiled with optimization levels "-O0", "-O1", "-O2", and "-O3"

[edumoot]

The value obtained by dereferencing the global pointer shared_ptr is inconsistent at line 38. It shows 1 in binaries compiled with "-O0" and "-O1", but displays 1139366573 in binaries compiled with "-O2" and "-O3". Godblot Link

We can reproduce this issue in LLVM versions 18.1.8, 17.0.6, and 16.0.3 :

clang -g -O3 -o 402_O3.out 402.c
clang -g -O2 -o 402_O2.out 402.c
clang -g -O1 -o 402_O1.out 402.c
clang -g -O0 -o 402_O0.out 402.c

(lldb) file 402_O3.out
(lldb) b 38
(lldb) r
[...]

(lldb) p *shared_ptr
(int) 1139366573


(lldb) file 402_O1.out
(lldb) b 38
(lldb) r
[...]

(lldb) p *shared_ptr
(int) 1

cat 402.c

struct S0 {
   volatile int f0;
   unsigned short f1;
};

union U3 {
   struct S0 f0;
   signed f1 ;
};

static unsigned global_flag = 1U;
static int global_var = 0x43E95AAD;
static int *const global_ptr = &global_var;
static volatile union U3 global_union = {{-1, 0x2079}};
static int helper_var = 0xCAAAA389;
static int main_var = 0x1340892D;
static int *const main_ptr = &main_var;
static int *const volatile shared_ptr = &global_var;

static unsigned execute_main(void);
static int *execute_func(unsigned long long param);
static unsigned helper_func(int *ptr1, int val, int *ptr2);

static unsigned execute_main(void) {
    int *local_ptr = &global_var;
    int **double_ptr = &local_ptr;

    *local_ptr &= global_flag;
    *shared_ptr = (*main_ptr ^= (execute_func(global_var) != main_ptr));
    return **double_ptr;
}

static int *execute_func(unsigned long long param) {
    long long temp_val = 0;
    int *result_ptr = &global_var;
    int *update_ptr = &helper_var;

    *update_ptr |= ((param < param) >= (global_union, helper_func(&global_var, (*result_ptr = (0xA7 + temp_val)), result_ptr)));
    return result_ptr;
}

static unsigned helper_func(int *ptr1, int val, int *ptr2) {
    int temp_var = -9;
    unsigned short temp_flag = 65535U;
    temp_flag++;
    return global_union.f0.f0;
}

int main(void) {
    execute_main();
    return 0;
}

GDB also demonstrates the same issue.

(gdb) file 402_O3.out
(gdb) b 38
(gdb) r
[...]
(gdb) p *shared_ptr
$5 = 1139366573


(gdb) file 402_O1.out
(gdb) b 38
(gdb) r
[...]
(gdb) p *shared_ptr
$4 = 1


$ gdb --version
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Yachao Zhu (edumoot)

The value obtained by dereferencing the global pointer `shared_ptr` is inconsistent at line 38. It shows `1` in binaries compiled with "-O0" and "-O1", but displays `1139366573` in binaries compiled with "-O2" and "-O3". [Godblot Link](https://godbolt.org/z/vj18asG5q)

We can reproduce this issue in LLVM versions 18.1.8, 17.0.6, and 16.0.3 :

clang -g -O3 -o 402_O3.out 402.c
clang -g -O2 -o 402_O2.out 402.c
clang -g -O1 -o 402_O1.out 402.c
clang -g -O0 -o 402_O0.out 402.c

(lldb) file 402_O3.out
(lldb) b 38
(lldb) r
[...]

(lldb) p *shared_ptr
(int) 1139366573


(lldb) file 402_O1.out
(lldb) b 38
(lldb) r
[...]

(lldb) p *shared_ptr
(int) 1

cat 402.c

struct S0 {
   volatile int f0;
   unsigned short f1;
};

union U3 {
   struct S0 f0;
   signed f1 ;
};

static unsigned global_flag = 1U;
static int global_var = 0x43E95AAD;
static int *const global_ptr = &global_var;
static volatile union U3 global_union = {{-1, 0x2079}};
static int helper_var = 0xCAAAA389;
static int main_var = 0x1340892D;
static int *const main_ptr = &main_var;
static int *const volatile shared_ptr = &global_var;

static unsigned execute_main(void);
static int *execute_func(unsigned long long param);
static unsigned helper_func(int *ptr1, int val, int *ptr2);

static unsigned execute_main(void) {
    int *local_ptr = &global_var;
    int **double_ptr = &local_ptr;

    *local_ptr &= global_flag;
    *shared_ptr = (*main_ptr ^= (execute_func(global_var) != main_ptr));
    return **double_ptr;
}

static int *execute_func(unsigned long long param) {
    long long temp_val = 0;
    int *result_ptr = &global_var;
    int *update_ptr = &helper_var;

    *update_ptr |= ((param < param) >= (global_union, helper_func(&global_var, (*result_ptr = (0xA7 + temp_val)), result_ptr)));
    return result_ptr;
}

static unsigned helper_func(int *ptr1, int val, int *ptr2) {
    int temp_var = -9;
    unsigned short temp_flag = 65535U;
    temp_flag++;
    return global_union.f0.f0;
}

int main(void) {
    execute_main();
    return 0;
}

GDB also demonstrates the same issue.

(gdb) file 402_O3.out
(gdb) b 38
(gdb) r
[...]
(gdb) p *shared_ptr
$5 = 1139366573


(gdb) file 402_O1.out
(gdb) b 38
(gdb) r
[...]
(gdb) p *shared_ptr
$4 = 1


$ gdb --version
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git

[OCHyams]

Thanks for the report @edumoot.

This looks like it's not a bug, and the (correct) behaviour you're observing is caused by optimisations removing redundant assignments to globals.

After inlining everything, LLVM has realised that the write to global_var on line 28 is redundant, as it gets overwritten by the assignment on line 38 (storing the value 167). So the line 28 assignment is omitted.

Using your godbolt example you can see that the first instruction in main sets global_var to 167. See https://godbolt.org/z/zoh5T17oe for disassembly and IR.

main:                                   # @main
.Lfunc_begin0:
        .cfi_startproc
# %bb.0:
        #DEBUG_VALUE: execute_func:temp_val <- 0
        .loc    1 38 93 prologue_end            # example.cpp:38:93
        mov     dword ptr [rip + global_var], 167  ; <--- first instruction in main
<snip>

That first instruction is from line 38 (see the directive loc 1 38 93 prologue_end or run llvm-dwarfdump --debug-line on it ).

Breaking on line 38 tells LLDB to stop before that instruction has executed. The value you're seeing, 1139366573, is global_var's initial value (0x43E95AAD). That is truthful as we've not yet stored anything else to the global.

I'm closing this as it looks like everything is working as intended. Please let me know if anything is unclear or I've have misinterpreted something here.

[dwblaikie]

FWIW I have mixed feelings here - I get your argument @OCHyams, and that probably is the one we should go with indefinitely - but /technically/ we could produce debug locations that show the global variable has a different value within the scope of the function. We do this for local variables as they move between storage (constant value, register, memory, etc) - but we don't do it for globals. DWARF doesn't really offer a great way to do this for globals - since in different files we might have hoisted/dead-store-eliminated/etc different operations on a global. But DWARF only provides one location for the global variable (so for a file-static local we could have local locations within certain instruction ranges, but for an extern global we can't have one file/one usage describe the optimizations of the global and have that merged with similar info in another file, etc).

But, yeah, it's a pretty broad problem/change in design direction - and for now we've got to basically accept that globals are described with a single location and expose users to all the effects of optimizations on that global...

[jmorse]

To improve my understanding,

so for a file-static local we could have local locations within certain instruction ranges,

How would this be achieved with current DWARF (assuming you mean it's possible), having a local-variable that shadows the global variable perhaps?

[pogo59]

having a local-variable that shadows the global variable perhaps?

That's an interesting idea. It would matter only when the global gets modified. It would suffer from the same issues as (for example) locals with a stack home but a temporary register location; a user command to modify the variable while in a temp location might not be reflected back to the home location. I suppose if the variable had a default-location, we could write non-normative words in the DWARF standard to say, you should probably update the default-location as well. Then if this artificial local has a default-location pointing back to the global, changes would be reflected appropriately.

Sorry for any incoherency, I'm writing this very quickly without giving it a huge amount of thought.

[dwblaikie]

To improve my understanding,

so for a file-static local we could have local locations within certain instruction ranges,

How would this be achieved with current DWARF (assuming you mean it's possible), having a local-variable that shadows the global variable perhaps?

My premise above was that it wasn't possible practically for non-file-scope-static variables - but that this is inconsistent with how we handle local variables, where we try to reflect the state without optimizations applied.

So for non-file-scope-static namespace-scope variables, I guess I mean "The current state of clang/LLVM is undesirable but DWARF Doesn't allow us to do anything better" is a more accurate answer than "The current state is correct because it accurately reflects the lost or sunk writes that the optimizer performed" - which is, to be fair, a bit of a "meh" point if it amounts to the same thing - but I thought the distinction (& inconsistency with local variables) was worth noting.

For file-scope-static variables, we could in theory have a location list with a default location of the global memory, but with a location list that had interesting ranges within functions where the global has a constant value, a register value, etc.

You make a fair suggestion that using a named local variable could be an interesting way around this problem - again, with a default location, that might work.

I'm not at all intending to suggest this should be anyone's highest priority, but just that we should consider it "not right" - but fairly hard/unclear problem to solve.

Re: @pogo59's point about storage/writability - I believe we can use different kinds of locations (eg: a location description that returns the value, rather the location - there's some way to draw that distinction) to ensure that we communicate that this is the /value/ of the variable, but not its storage, when necessary. But I don't think we do that in LLVM otherwise - I imagine there are issues today with our locations where perhaps we have the value in a register that isn't reflected back to some authoritative backing storage (even a local/non-global situation) so I'm not sure that's a new/distinct problem in this domain.... but maybe?