On Wed, Mar 24, 2021 at 10:11:19AM +0100, Maciej Zdeb wrote: > Wow, that's it! :) > > 0x000055d94949e965 <+53>: addl $0x1,%fs:0xfffffffffffdd688 > 0x000055d94949e96e <+62>: callq 0x55d9494782c0 <realloc@plt> > 0x000055d94949e973 <+67>: subl $0x1,%fs:0xfffffffffffdd688 > [...] > 0x000055d94949e99f <+111>: ja 0x55d94949e9b0 <hlua_alloc+128> > 0x000055d94949e9a1 <+113>: mov %rbx,%rdi > 0x000055d94949e9a4 <+116>: callq 0x55d949477d50 <malloc@plt> > 0x000055d94949e9a9 <+121>: test %rax,%rax > [...] > 0x000055d94949e9c1 <+145>: addl $0x1,%fs:0xfffffffffffdd688 > 0x000055d94949e9ca <+154>: callq 0x55d949477b50 <free@plt> > 0x000055d94949e9cf <+159>: subl $0x1,%fs:0xfffffffffffdd688 >
Cool! > Ok I'll make hlua_not_dumpable volatile instead of applying compiler > barriers. Yes, it's safer for the long term as nobody will have to think about it anymore. We'll have to integrate this one as well. I'm wondering how many programs do *really* benefit from having gcc have a builtin malloc that bypasses the library-provided allocator, compared to all the ones experiencing pain and breakage, especially when using a non-legacy allocator or a debug-enabled one :-/ Willy
