On 9/19/19 4:13 PM, Christophe Lyon wrote:
On Tue, 17 Sep 2019 at 14:08, Christophe Lyon <christophe.l...@st.com>
wrote:
>
> On 17/09/2019 13:38, Wilco Dijkstra wrote:
> > Hi Christophe,
> >
> > Can you explain this in more detail - it doesn't make sense to me
to force the
> > Thumb bit during unwinding since it should already be correct,
even on a
> > Thumb-only CPU. Perhaps the kernel code that pushes an incorrect
address on
> > the stack could be fixed instead?
> >
> >> Without this, when we are unwinding across a signal frame we can jump
> >> to an even address which leads to an exception.
> >>
> >> This is needed in __gnu_persnality_sigframe_fdpic() when
restoring the
> >> PC from the signal frame since the PC saved by the kernel has the LSB
> >> bit set to zero.
> >
> > Wilco
> > .
> >
>
> Indeed, I've noticed the problem mentioned by Matthew since I
committed that patch.
>
> I was about to propose a fix, replacing #if (__thumb__) with #if
(!__ARM_ARCH_ISA_ARM), but you are right: maybe the kernel code should
be fixed instead.
>
> So far I haven't managed to reproduce a failure in FDPIC mode
without this patch though...
>
> Thanks and sorry for the breakage.
>
I'm having problems with the board I use for testing, so I propose to
revert that patch until I have a better description of the problem it
fixed.
OK?
Ok by me as long as lives the fdpic toolchain in a usable state (barring
the potential issue here)
Thanks,
Kyrill
Christophe
> Christophe
>
