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-l...@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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"