[lttng-dev] Bogus openembedded gcc patch

[Khem Raj]

On Jan 26, 2016 2:59 PM, "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
wrote:
>
> ----- On Jan 26, 2016, at 11:28 AM, Khem Raj raj.khem at gmail.com wrote:
>
> >> On Jan 25, 2016, at 8:02 PM, Mathieu Desnoyers <
mathieu.desnoyers at efficios.com>
> >> wrote:
> >>
> >> Hi,
> >>
> >> We are noticing the presence of the following patch in various
> >> openembedded gcc versions:
> >>
> >> 0024-PR-target-32219.patch
> >>
> >> "From e0d15f4f8bf28c351b9215ca37f1caa24df0e1fd Mon Sep 17 00:00:00 2001
> >> From: Khem Raj <raj.khem at gmail.com>
> >> Date: Fri, 29 Mar 2013 09:18:54 +0400
> >> Subject: [PATCH 24/35] PR target/32219
> >>
> >> * varasm.c (default_binds_local_p_1): Weak data is not local.
> >>
> >> Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop at gmail.com>
> >> Signed-off-by: Khem Raj <raj.khem at gmail.com>
> >>
> >> Upstream-Status: Backport"
> >>
> >> However, contrarily to its "Backport" status, that patch is
> >> not upstream in gcc, and we're starting to wonder if this
> >> would be the patch that breaks handling of start/stop automatic
> >> hidden symbols we use in lttng-ust.
> >>
> >> We are only experiencing problems on the various openembedded
> >> compilers, but on no other distro (with same compiler versions),
> >> which leads us to suspect a buggy distro-specific gcc patch.
> >>
> >> We've been testing with openembedded gcc-4.9.2-r0.
> >>
> >> The original gold linker issue that this patch was trying to
> >> address seems to have been fixed in the gold linke since
> >> then.
> >>
> >> Refs:
> >> http://lists.lttng.org/pipermail/lttng-dev/2014-May/023112.html
> >> https://gcc.gnu.org/ml/gcc-help/2014-05/msg00042.html
> >>
http://cgit.openembedded.org/openembedded-core/commit/?id=3cb2b003db7371b3a47d02c08352a262e1e419b4
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=15435
> >>
> >> Thoughts ?
> >
> > OE has defaulted to gcc5 since last release, and gold issue is fixed in
binutils
> > 2.25
> > which is what we use in 2.0 as well so it might be OK to unbolt this
fix.
> > Although I am not sure
> > about the original problem reported in PR32219 is fixed for gcc 4.9 if
we remove
> > this fix.
> > Have you narrowed down your issue to this patch ? if not, then it would
be good
> > to do so
>
> Yes, we have narrowed down our problem to this specific patch by
> removing the patch from the OE gcc patches, rebuilding gcc, and
> then building our test program with that gcc. The problem goes
> away when we do so, which points directly to that patch as a
> culprit.
>
> Test program is attached.

Ok I think we can remove this from master and jethro release
>
> Faulty[gcc 4.9-r0 with patch 0024]:
>
> main: myvar addr=0x600c90 __start___test=0x600c90
> fct: myvar addr=0x7f8733d1eae8 __start___test=0x600c90
> fct2: myvar addr=0x7f8733d1eaec __start___test=0x600c90
> fct3: myvar addr=0x600c94 __start___test=0x600c90
>
> Valid[gcc 4.9-r0 without patch 0024]:
>
> main: myvar addr=0x600c60 __start___test=0x600c60
> fct: myvar addr=0x7fb62c758a90 __start___test=0x7fb62c758a90
> fct2: myvar addr=0x7fb62c758a94 __start___test=0x7fb62c758a90
> fct3: myvar addr=0x600c64 __start___test=0x600c60
>
> Thanks,
>
> Mathieu
>
> >
> >>
> >> Thanks,
> >>
> >> Mathieu
> >>
> >> --
> >> Mathieu Desnoyers
> >> EfficiOS Inc.
> > > http://www.efficios.com
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20160126/9fae36bf/attachment.html>