Gregory's Serveroh my fucking god. so i was having a problem when i enabled optimizations when compiling the doom port. memcpy ended up overwriting itself. so i looked into what was happening, and apparently memcpy just kept calling itself over and over. the reason? i was compiling my own version of memcpy, because i wasn't using the standard library, but i also didn't use the "-ffreestanding" flag, so gcc assumed i *did* have the standard library. so gcc, in its infinite wisdom, saw a memcpy-like pattern in my memcpy and turned it into another call to memcpy, resulting in a stack overflow.
 35 comments | Expand all CWs
 @nil (definitely a wtf moment, jokes aside. But I expect nothing less from GCC at this point)  @jhwgh1968 @nil you want to call memcpy so I called memcpy. so what if that memcpy also calls memcpy? not my problem @nil i dont know much about riscv but even assuming that was correct surely such an optimization couldve just been like. a `jmp memcpy` @mothcompute @nil wouldnt you still need to be able to know where to return? a simple branch couldn't cut it
 @ireneista @nil clang also does this! it's a classic firmware dev issue you cannot implement the C standard library in (standard, non-freestanding) C by the explicit design of C  @whitequark @ireneista @nil I'm honestly kind of confused why nostdlib and freestanding are separate switches  @eniko @whitequark @ireneista @nil Afaik freestanding is an option for the compiler itself while nostdlib is effectively an option for the linker (or rather to control the linker inputs), maybe that's the reason they're separate  @lisyarus @eniko @whitequark @ireneista @nil Is there a reason you wouldn't want them synched up to be the same either way? @eniko @whitequark @ireneista @nil I think freestanding is "there is no memcpy" and nostdlib is "I brought my own memcpy" so you'd use one for your memcpy and friends and the other for the rest of your very custom system?   @nil@furry.engineer       @nil I was just discussing this with my dad the other day in explaining how sometimes the compiler is too intelligent and unless you know how to debug it and the resulting compiled code you’re stuck with a mystery you can’t solve; making some ASM experience mandatory for debug purposes.  @carbontwelve It's not "too intelligent", it's "not intelligent enough". If it was intelligent enough, it would've seen it's seeing something memcpy-like because it's compiling a memcpy. @nil i dont have access to a computer with gcc atm, so I cannot check: does this happen at O1? i'm also wondering how gcc detects this "pattern". if it's based on the function name, then that seems outright passive-aggressive. if it's based on the code structure, it seems really brittle and I would not expect that at low optimization levels.  @nil yeah I think everyone who uses a C compiler runs into this eventually. Next up is cross-compiling to a different arch that works just fine until you upgrade your toolchain and then you learn that the compiler is now emitting calls to libcompiler_rt.a, which you don't have because your target isn't your native arch, but so far it's been working fine because the previous version of the toolchain just happened to never emit any such calls for your codebase.  > gcc, in its infinite wisdom, saw a memcpy-like pattern in my memcpy and turned it into another call to memcpy, Insert Jurassic Park quotes here. @nil You can also use -fno-builtin-memcpy to disable this optimisation (and similar options for other standard library functions) |
@nil *nods dryly* so what's the problem here?