[OE-core] [PATCH] glibc: add -fno-builtin-strlen when not using -O2

[Huang, Jie (Jackie)]

> -----Original Message-----
> From: Andre McCurdy [mailto:armccurdy at gmail.com]
> Sent: Monday, December 12, 2016 5:55 PM
> To: Huang, Jie (Jackie)
> Cc: Khem Raj; Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH] glibc: add -fno-builtin-strlen when not using -O2
> 
> On Sun, Dec 11, 2016 at 11:41 PM, Huang, Jie (Jackie)
> <Jackie.Huang at windriver.com> wrote:
> >> -----Original Message-----
> >> From: Khem Raj [mailto:raj.khem at gmail.com]
> >> Sent: Monday, December 12, 2016 2:37 PM
> >> To: Huang, Jie (Jackie)
> >> Cc: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH] glibc: add -fno-builtin-strlen when not using -O2
> >>
> >> On Sun, Dec 11, 2016 at 9:42 PM,  <jackie.huang at windriver.com> wrote:
> >> > From: Jackie Huang <jackie.huang at windriver.com>
> >> >
> >> > The strlen will be inlined when compile with -O, -O1 or -Os,
> >> > so there is no symbol for strlen in ld-linux-x86-64.so.2,
> >> > causing a fatal error in valgrind:
> >> >
> >> > valgrind: Fatal error at startup: a function redirection
> >> > valgrind: which is mandatory for this platform-tool combination
> >> > valgrind: cannot be set up. Details of the redirection are:
> >> > valgrind:
> >> > valgrind: A must-be-redirected function
> >> > valgrind: whose name matches the pattern: strlen
> >> > valgrind: in an object with soname matching: ld-linux-x86-64.so.2
> >> >
> >> > so add -fno-builtin-strlen when compile with -O, -O1 or -Os.
> >>
> >> This is a bug in valgrind, I read the same on forums. KDE has proposed a fix
> >> https://bugsfiles.kde.org/attachment.cgi?id=82043
> >> can you check if this fixes the issue
> >
> > Thanks, I will check that and change to patch for valgrind if it works.
> 
> For reference, here's the patch I've been using. It's a slightly more
> generic fix than the one in the KDE bug report.

Thanks, It's a better patch and I will take it and send as v2 of this issue if you're
not going to send it yourself, is it fine for you and could you provide extra info
for the patch header like, upstream-status, written by or Signed-off-by?

Thanks,
Jackie

> 
> diff --git a/coregrind/m_redir.c b/coregrind/m_redir.c
> index 7e4df8d..640a346 100644
> --- a/coregrind/m_redir.c
> +++ b/coregrind/m_redir.c
> @@ -1220,7 +1220,18 @@ static void add_hardwired_spec (const  HChar*
> sopatt, const HChar* fnpatt,
>     spec->from_fnpatt = CONST_CAST(HChar *,fnpatt);
>     spec->to_addr     = to_addr;
>     spec->isWrap      = False;
> -   spec->mandatory   = mandatory;
> +
> +   /* Hack: Depending on how glibc was compiled (e.g. optimised for size or
> +      built with _FORTIFY_SOURCE enabled) the strlen symbol might not be found.
> +      Therefore although we should still try to intercept it, don't make it
> +      mandatory to do so. We over-ride "mandatory" here to avoid the need to
> +      patch the many different architecture specific callers to
> +      add_hardwired_spec(). */
> +   if (0==VG_(strcmp)("strlen", fnpatt))
> +      spec->mandatory = NULL;
> +   else
> +      spec->mandatory = mandatory;
> +
>     /* VARIABLE PARTS */
>     spec->mark        = False; /* not significant */
>     spec->done        = False; /* not significant */