Segfault in _Unwind_* code called from pthread_exit

[Konstantin Belousov]

On Tue, Oct 31, 2017 at 08:37:29PM +0100, Andreas Tobler wrote:
> On 31.10.17 10:28, Konstantin Belousov wrote:
> > On Mon, Oct 30, 2017 at 10:54:05PM +0100, Andreas Tobler wrote:
> >> On 30.10.17 15:32, Tijl Coosemans wrote:
> >>> On Sun, 29 Oct 2017 20:40:46 +0100 Andreas Tobler <andreast-list at fgznet.ch> wrote:
> >>>> Attached what I have for libgcc. It can be applied to gcc5-8, should
> >>>> give no issues. The mentioned tc from this thread and mine,
> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 do pass.
> >>>>
> >>>> What do you think?
> >>>
> >>> Like I said before the return address can be anything.  It could for
> >>> instance point to some instruction in a random function and then the
> >>> stack unwinder will think thread_start was called from that function.
> >>> There's no check you can add to libgcc to distinguish that from a
> >>> normal valid return address.
> >>>
> >> Maybe not, and most probably I do not understand what is happening. But
> >> with my modification I survive the test case.
> >>
> >> If no objections from your or Konstantin's side come up I will commit it
> >> to the gcc repo. It will not 'fix' the issue, but it will improve the
> >> gcc behavior.
> > 
> > I posted something similar when the discussion thread started. From the
> > cursory look, your patch is better than mine. The only difference that
> > makes me wonder is that I used #ifdef KERN_PROC_SIGTRAMP around the
> > block because I believe gcc has more relaxed policy about supporting
> > obsoleted OS versions.
> 
> I am aware about KERN_PROC_SIGTRAMP and older OS releases, that's why I 
> asked for feedback.
> Do we, FreeBSD'ers, want to have gcc unwind support on older than 
> FreeBSD 9.3 releases? I think the gcc folks do not care, but we are the 
> ones who might have an need for such a support?
Well, I put the #ifdef because I suspected that gcc folks cared, if
anybody.  For instance I know that perl people do.

Is there some specific configuration bits in gcc that are only relevant for 
older releases ?  If yes, then we perhaps should not break them until
removed.  If not, then it does not matter, most likely.

> @Gerald, do you have an opinion?
> 
> I can 'ifdef' the new code and in the 'else' case we fall back to the 
> already existing path.