[cfe-dev] [UBSan] Is static linking supported?

[Evgenii Stepanov via cfe-dev]

Standalone ubsan has a few interceptors to handle signals - in
particular, handle_segv=2 (and others) blocks the user program from
replacing the signal handler. Ignoring return value of 0 from dlsym
would not work, because then the libc sigaction() is unreachable.

I wonder if there should be a separate version of the runtime library
for use with fully static binaries?


On Thu, Aug 23, 2018 at 11:40 AM, Vedant Kumar <vsk at apple.com> wrote:
> On Aug 23, 2018, at 11:27 AM, Richard Smith <richard at metafoo.co.uk> wrote:
>
>
> On Thu, 23 Aug 2018, 11:13 Vedant Kumar via cfe-dev,
> <cfe-dev at lists.llvm.org> wrote:
>>
>> > On Aug 23, 2018, at 10:59 AM, David Greene <dag at cray.com> wrote:
>> >
>> > According to Reid Kleckner over on llvm-dev sanitizers will not work at
>> > all with a statically-linked libc, as the interceptors use dlsym to set
>> > up calls to sigaction and the like.  That matched my findings while
>> > debugging the problem we're seeing.
>>
>> Good point, that might be the issue here.
>
>
> UBSan, unlike the other sanitizers, was explicitly designed to not perform
> any interception. It's possible that has changed in the interim, of course
> ...
>
>
> Ah, you're right, I don't think that's changed.
>
> The standalone version of the UBSan runtime used on Windows does install its
> own signal handlers. Maybe that causes a bad interaction with Troy's
> program?
>
> vedant
>
>
>> > If sanitizers are supposed to work
>> > with static linking, then it seems like the dependence on dlsym needs to
>> > be broken.
>> >
>> > Otherwise, the sanitizers should catch a nullptr return value from dlsym
>> > and report a friendly user error message.  I can write a patch to do
>> > that if it seems like a good idea.  Even when linking dynamically, it
>> > would be good to check the return value of dlsym and report the error to
>> > the user.
>>
>> + 1.
>>
>> vedant
>>
>>
>> >
>> >                           -David
>> >
>> > Vedant Kumar via cfe-dev <cfe-dev at lists.llvm.org> writes:
>> >
>> >> On some platforms it's possible to statically link against the
>> >> ASan/UBSan runtimes using the undocumented -static-libsan option. The
>> >> default behavior on Darwin, Android, and Fuchsia is to link against a
>> >> DSO.
>> >>
>> >>    On Aug 23, 2018, at 8:57 AM, Troy Johnson via cfe-dev
>> >>    <cfe-dev at lists.llvm.org> wrote:
>> >>
>> >>
>> >>
>> >>
>> >>    The address sanitizer is documented as not supported with static
>> >>    linking, but UBSan does not include the same disclaimer. UBSan
>> >>    does not work for me with statically-linked executables. Instead,
>> >>    the executables segfault immediately when attempting to install
>> >>    signal handlers. Is this expected?
>> >>
>> >> No, that's not expected :). Could you share the options you used to
>> >> compile and link it, and the backtrace you get?
>> >>
>> >> vedant
>> >>
>> >>
>> >>
>> >>    -Troy
>> >>
>> >>
>> >>    _______________________________________________
>> >>    cfe-dev mailing list
>> >>    cfe-dev at lists.llvm.org
>> >>    http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> cfe-dev at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>