https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
Wilco <wilco at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wilco at gcc dot gnu.org
--- Comment #5 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> I think the bug is in the assembler or the linker:
> .L22:
> .word myhandler2-1
>
>
>
> Basically what is happening is:
> (__handler != ((__sighandler_t) 2)) && (__handler != ((__sighandler_t)
> SIG_DFL))
>
> is converted to:
>
> (((size_t)__handler)-1) <= 1
>
> And then GCC emits myhandler2-1 in the constant pool which is correct but
> the assembler/linker decides to put 0x200003a7 in that location (See the
> .L22 above) and then GCC adds +1 to it to try to make it myhandler2 (again).
>
> This is why using SIG_DFL of 5 works, it is just by accident because GCC
> decides not to do the transformation or put myhandler2-1 in the constant
> pool.
>
> Again I think this is an assembler/linker issue of putting the wrong value
> for
>
> .L22:
> .word myhandler2-1
The +1 is added by the assembler since it is a Thumb function. Then the
compiler adds another +1, making it +2. Basically one shouldn't do arithmetic
with function symbols since bit 0 encodes the Arm/Thumb state.
