https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119314
--- Comment #6 from Novel <root at hsnovel dot net> --- (In reply to Andrew Pinski from comment #5) > (In reply to Novel from comment #0) > > > ; CODE XREF from sym.IGNORE_THIS_ITS_FUNCTION_NAME @ 0x8bcc(x) > > ; 0x28f58 > > lea rdi, section..got > > call fcn.00006260;[ob] > > ; int64_t arg3 > > mov rdx, rbp > > ; int64_t arg1 > > mov edi, 2 > > ; int64_t arg2 > > ; 0x234e6 > > ; "2 Data %p\n" > > lea rsi, str.2_Data__p_n > > mov rax, qword [rax] > > add rbx, qword [rax + 0x10] > > xor eax, eax > > mov r13, qword [rbx + 8] > > mov ebx, dword [rbx + 0x10] > > call sym.log_log;[oa] > > xor eax, eax > > ; int64_t arg3 > > mov edx, r14d > > ; int64_t arg1 > > mov edi, 2 > > ; int64_t arg2 > > ; 0x234f1 > > ; "2 Size %d\n" > > lea rsi, str.2_Size__d_n > > call sym.log_log;[oa] > > test rbp, rbp > > je 0x8a98 > > Test %RBP . > > So if a function does not restore correctly %RBP things could go wrong. > > Also try running your test program under valgrind, it might catch some stuff > too. > > The other thing to try is change log_info to be a just printf. > > There could be a bug in musl fprintf too that is not restoring some register > correctly. It is not obvious what is going on here from even the snip of > code. I tested it today and neither valgrind nor sanitizer did report anyhting related to this. I did link with glibc, instead of musl and tested printf but it's still the same. I am not sure if further discussion in this report would be usefull to any gcc maintainer, as I am not able to provide much information unfortunately. I can test other things, if some maintainer wants me to experiment with some flag somehow, otherwise you can close this report when you see fit.
