On Sat, Jan 25, 2014 at 7:02 AM, Ondřej Bílka <[email protected]> wrote:
> On Fri, Jan 24, 2014 at 05:12:28PM -0800, Paul Pluzhnikov wrote:
>> On Fri, Jan 24, 2014 at 5:05 PM, Ondřej Bílka <[email protected]> wrote:
>>
>> > There would be a possible hack to override mmap and look for mmap that
>> > with dl_addr in backtrace.
>>
>> That is unlikely to work:
>>
>> (gdb) disas __signal_safe_memalign
>> Dump of assembler code for function __signal_safe_memalign:
>> ...
>> 0x00000000000103e2 <+114>: callq 0x18500 <mmap64>
>> ...
>>
>> That is, the call to mmap64 does not go through PLT, and overriding it is
>> just as difficult as overriding __signal_safe_memalign :-(
>>
> I did not considered this one. As mmap is quite slow there is no deep
> reason for it.
>
> We would need to make also mmap there go via plt by same logic.
exporting mmap will probably have some other unpredictable
consequences and is even less likely to be acceptable at the "release
freeze" stage.
> > How do I "export" __signal_safe_memalign? (I/d like to experiment myself)
> You'll need this snippet of above patch: (line 61,5):
Paul, I tried this:
--- a/elf/Versions
+++ b/elf/Versions
@@ -62,5 +62,8 @@ ld {
# Pointer protection.
__pointer_chk_guard;
+ # for signal safe TLS
+ __signal_safe_malloc; __signal_safe_free; __signal_safe_memalign;
+ __signal_safe_realloc; __signal_safe_calloc;
}
}
it did not help: "nm libc.so | grep signal_safe_memalign" is empty.
--kcc
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
