m68k/cpu32 TRAP instruction?

[Xi Ruoyao]

On 2018-10-05 23:14 +0200, Josef Wolf wrote:
> On Thu, Oct 04, 2018 at 03:19:56PM -0600, Jeff Law wrote:
> > On 10/4/18 1:39 PM, Josef Wolf wrote:
> > > When gcc inserts trap instructions, it assumes that there is some sort of
> > > hanlder installed for this? How should such a handler look like? I'd rather
> > > have the handler output some useful diagnostics instead of just crashing.
> > 
> > It's up to the application to figure out how to handle this situation.
> > 
> > The compiler only inserts the traps when it can prove conclusively that
> > the program will trigger undefined behavior at a particular execution point.
> 
> I think it's the other way around: the trap is inserted when gcc sees a chance
> for NULL-dereference.
> 
> > Stopping the program immediately is far better than the compiler trying
> > to issue diagnostics or anything like that.
> 
> I'd very much prefer a warning at compile time! With a warning, I'd have a
> chance to fix the problem before the trap is taken in production.
> 
> I fail to see any good in this trap:

In my POV an undefined behavior is just like __builtin_unreachable() because
the compiler can assuems all undefined behaviors are unreachable.  It's a
common precedure to use __builtin_trap() instead of __builtin_unreachable()
while debugging:

#ifdef NDEBUG
#define unreachable() __builtin_unreachable()
#else
#define unreachable() __builtin_trap()
#endif

> - If the compiler can detect such a serious problem, then it should emit a
>   warning AT COMPILE TIME.

Then we should emit warnings for all "*p" unless we can prove "p" is not NULL.
It's easy to see the proving requires to solve halting problem :).

Don't tell me you will like such warnings to spam you terminal:

    warning: undefined behavior may be invoked depending on the content of 's':
            r = sscanf(s, "%d", &x);
                ~~~~~~~^~~~~~~~~~~~
    note: according to C1X-N1570 7.21.6.2p10 if 's' is a pointer to the first
    byte of '666666666666666666' this would invoke undefined behavior, but we
    can't prove 's' is not such a pointer.  You may wish to use HOL theorem-
    proving system <https://sourceforge.net/projects/hol/> to prove or disprove
    this proposition.

> - If the compiler inserts a trap, then this trap should improve the situation
>   instead of making it worse.
> 
>   Simply crashing leaves you without any clue. You have no idea where to look
>   for the bug. The crash could even be by a power outage. That's not exactly
>   improving the situation.

You have GDB.

>   Issuing a diagnostic "Oops, NULL-dereference at adsf.c:123" would improve
>   the situation: you know where to look for the fix.

You have -fsanitize=undefined.

> > You're in the world of
> > undefined behavior, the safe thing to do is halt immediately.
> 
> Whether stopping immediately is good or not depends very much on the context.

Then what?  Just leave it undefined and format your disk, or run a game from
/usr/game?  GCC used to do this and then was blamed by a CVE.

> Instead of stopping immediately, I'd also prefer to get something like
> "hey NULL-dereference at foobar.c:123. Stopping now."

You have -fsanitize=undefined.  Or you can just wrap this into a macro like
many projects (including GCC itself).

> > That indicates a deeper problem (the existence of the call changing the
> > paths through the program.
> 
> The existence of a call to a function with potential side effets (e.g. printf)
> can AND WILL very much change paths due to the fact that the optimizer needs
> to drop some assumptions.

The optimizer just follows the standard.  It's not an AI and can't guess what's
in your mind.

> > I'll repeat, if the compiler is inserting traps, the program is horribly
> > buggy  at those points.  You should dig into why.
> 
> If this would be true, then traps in a program that is guaranteed to never
> dereferencing NULL would be an indication of bugs in the compiler?

You can prove many lemmas and theorems to prove a program is guaranteed not to
dereferencing NULL.  But the compiler can not.  It is designed to compile C
programs according to ISO/IEC 9899, not to prove theorems.  The standard does
not require a C compiler to solve halting problem, after all.

This series of article from LLVM blog has answered all of your questions:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
GCC wiki is your friend:
http://gcc.gnu.org/wiki/FAQ#undefinedbut
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University