[cfe-dev] -fcatch-undefined-behavior false positive with readdir()?

[Sean Silva]

> how is this reporting emitted exactly? in particular, will it be usable
> from a kernel context? i've been trying to enable -fcatch-undefined-behavior
> for linux for some time now and it caught interesting bugs but with the
> addition of alignment checking it doesn't even get past self-decompression ;).
> obviously any reporting at that point is not exactly trivial and were it
> not for qemu, it'd be painful to debug...

The instrumentation would need to be adjusted, but I don't think it
will be that difficult to get a reasonable behavior. You can just
core-dump the kernel, even if you're running on bare metal. You of
course will have to protect from a "recursive" UB dump in the IO path
when writing out the core, but otherwise it's pretty straightforward.

Another option which is basically the same but would allow for the
kernel to continue operating uninterrupted would be to essentially
"fork" the kernel and leave it frozen there in the state where the UB
triggered. You could then take advantage of Copy-On-Write to avoid the
lengthy dumping procedure, while still preserving the state of the
kernel when the UB occurred. This wouldn't require too much code, but
the code that it does need is very "tricky".

--Sean Silva


On Thu, Sep 27, 2012 at 6:35 AM, PaX Team <pageexec at freemail.hu> wrote:
> On 26 Sep 2012 at 23:05, Richard Smith wrote:
>
>> $ ./a.out
>> dirent.cpp:4:19: fatal error: member access within misaligned address
>> 0x7ffff752f787 for type 'struct dirent' requiring 8 byte alignment
>> zsh: illegal hardware instruction (core dumped)  ./a.out
>> $
>>
>> ... coming soon to a -fcatch-undefined-behavior near you. Snippet,
>> backtrace, etc. to follow.
>
> how is this reporting emitted exactly? in particular, will it be usable
> from a kernel context? i've been trying to enable -fcatch-undefined-behavior
> for linux for some time now and it caught interesting bugs but with the
> addition of alignment checking it doesn't even get past self-decompression ;).
> obviously any reporting at that point is not exactly trivial and were it
> not for qemu, it'd be painful to debug... so what i'm trying to say is
> that verbose reporting is nice but a mechanism to selectively disable UB
> checking subfeatures would also be useful.
>
> cheers,
>   PaX Team
>