Hi Andrew,
The problem with calling __builtin_trap directly comes when several
traps are called in the same function. For example, if a function
contains several identical assertions on different code paths, then gcc
will generate a single copy of the assertion, and branch to that copy
from each of the original assertion sites. If an assertion is hit, it
becomes impossible to tell which of the original source assertions this
relates to. Note that this is an embedded processor, so the source line,
error description and so on can't be embedded in the assertion, since
that consumes too much space; all an assertion does is test the
condition, and possibly call the HALT.
I defined my own builtin to access the HALT, in such a way that every
time a HALT instruction is generated, it is assigned a unique id. This
id does nothing (it just generates a comment in the assembly output),
but its presence is enough to fool the compiler into treating identical
source assertions as though they were different. This means that the
different assertions get their own HALT's, and if a HALT is detected at
runtime, the debugger can easily determine which source assertion this
relates to.
Thanks,
dan.
I maintain a port of gcc for an embedded processor which has a HALT
instruction. This instruction stops the processor, and generates an
appropriate interrupt to indicate to its parent system that it has
stopped. The instruction is accessed by the programmer using a
port-specific builtin, which can then be used, amongst other things, to
implement the `assert' macro.
Why doesn't this HALT instruction map directly to the trap builtin?
Isn't that a better way of doing it then using a port specific builtin?
-- Pinski
--
============================================================================
Daniel Towner
picoChip Designs Ltd, Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG
[EMAIL PROTECTED]
+44 (0) 7786 702589
