m68k/cpu32 TRAP instruction?

Jeff Law law@redhat.com
Fri Oct 5 21:31:00 GMT 2018


On 10/5/18 3:14 PM, 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.If you hit the trap at runtime, then you were going to dereference a
null pointer.  It's that simple.




> 
>> 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:
Well, your opinion and mine differ considerably.  GCC has worked like
this for years and it's exposed a bug in your code.  You have a few
options.  Fix your code, use an old compiler or turn off the behavior
with a switch.


> 
> - If the compiler can detect such a serious problem, then it should emit a
>   warning AT COMPILE TIME.
We don't for various reasons.  Frankly, I think we should as well, but I
lost that battle.

> 
> - If the compiler inserts a trap, then this trap should improve the situation
>   instead of making it worse.
It does improve things significantly.

> 
>   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.
I would disagree strongly.

> 
> 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.
Again, if you encounter one of these traps, then your program was going
to dereference the null pointer.  I know.  I wrote the code.


> 
>> 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?
If the runtime branching behavior does not lead to the path where the
trap was inserted, then you won't get a runtime trap.  We can't solve
the halting problem, obviously.

But when the compiler sees a *0 and it'll turn that into a trap.  It
also will isolate paths to a dereference where one or more paths would
result in a *0.  The isolated paths will get a trap, the normal paths
will be left alone.

The same thing is done for division by zero.

But again, the compiler has exposed a bug in your program.  Your best
course of action is to fix your code.

jeff




More information about the Gcc-help mailing list