I'm using x86-64-linux AOT-generated pipelines, statically linked in my binary. When I hit a halide_assert(), while running in the debugger, a backtrace never shows me where this function was actually called. It seems that calling conventions are not respected, and thus backtrace algorithms fail. I get something like this:
#0 0x00007ffff747a664 in __pthread_kill_implementation () at /usr/lib64/libc.so.6
#1 0x00007ffff7421c4e in raise () at /usr/lib64/libc.so.6
#2 0x00007ffff7409902 in abort () at /usr/lib64/libc.so.6
#3 0x0000000000980549 in halide_default_error ()
#4 0x0000000000989cbe in Halide::Runtime::Internal::(anonymous namespace)::HeapPrinter<(Halide::Runtime::Internal::PrinterType)1, 1024ul>::~HeapPrinter() [clone .120] ()
#5 0x000000000098a096 in halide_error_access_out_of_bounds ()
#6 0x0000000000873c87 in neonraw_bilateral_grid_loglum_constructor_8-x86-64-linux-avx2-fma-profile-cuda-no_bounds_query-no_runtime ()
#7 0x00000000008723a5 in neonraw_bilateral_grid_loglum_constructor_8 ()
#8 0x0000000000fcf040 in ??? ()
#9 0x3f0758b53ca0a0a1 in ??? ()
#10 0xbe651cc63f605ac1 in ??? ()
#11 0x00000000300040c8 in ??? ()
#12 0x0000000000000000 in ??? ()
So everything until frame #7 seems fine, but afterwards is total gibberish. Note that the function does correctly return and there is no bugs in control flow. It's just not debuggable if you can't go to the call-site.
I'm using
x86-64-linuxAOT-generated pipelines, statically linked in my binary. When I hit ahalide_assert(), while running in the debugger, a backtrace never shows me where this function was actually called. It seems that calling conventions are not respected, and thus backtrace algorithms fail. I get something like this:So everything until frame
#7seems fine, but afterwards is total gibberish. Note that the function does correctly return and there is no bugs in control flow. It's just not debuggable if you can't go to the call-site.