[LLVMdev] Intercepting dlinfo in memory sanitizer

[Keno Fischer]

Thanks! I'll try that.

In order to avoid starting a new thread, let me ask you the next question.
One of the shared libraries I load calls strtol and msan fails to intercept
it. Why would this be? The library seems to be otherwise implemented. One
of the potential culprits I saw is that strtol is marked as strong in libc.
Is there any workaround?

Keno

On Thu, Apr 9, 2015 at 3:00 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>
wrote:

> On Thu, Apr 9, 2015 at 9:24 PM, Keno Fischer
> <kfischer at college.harvard.edu> wrote:
> > Hi everyone,
> >
> > I ran into a false positive with memory sanitizer due to it not
> intercepting
> > dlinfo. I tried to get started on writing such an interceptor, but dlinfo
> > seems like an extraordinarily difficult function to intercept. The three
> > considerations that I would like somebody to look at are:
> >
> > 1) How do we get the enum values to decide what kind of pointer dlinfo is
> > getting. Ideally we'd include dlfcn.h, but the interceptor file doesn't
> > generally include system headers. What's the right thing to do here?
>
> We generally redefine system constants and types in
> sanitizer_platform_limits_posix.h and verify correctness with
> assertions in .cc.
>
> > 2) The structures pointed to contain linked lists, etc. of dynamic linker
> > state. In order to avoid spurious failures, it seems like we should
> iterate
> > the linked lists and unpoison all of them, but that seems expensive. Do
> you
> > see a better solution?
>
> Nope, sounds like that's want you need to do.
>
> > 3) The return values include pointers into the object files. It seems
> > perfectly reasonable for a user to want to read these object files based
> on
> > information from dlinfo. That probably means we should unpoison them as
> > well? Do we need to do something here or are these already unpoisoned by
> > some other mechanism (e.g. because msan realizes they are part of a
> loaded
> > object file or unposions them on load - does this happen?).
>
> They are unpoisoned. All memory defaults to unpoisoned (shadow == 0),
> and we take care of unpoisoning all memory we return to the OS.
>
> >
> > Thanks,
> > Keno
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150409/2f14e4a7/attachment.html>