This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ARM/FDPIC v6 13/24] [ARM] FDPIC: Force LSB bit for PC in Cortex-M architecture



On 9/19/19 4:13 PM, Christophe Lyon wrote:
On Tue, 17 Sep 2019 at 14:08, Christophe Lyon <christophe.lyon@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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]