[PATCH] rtems/gdb: Fix powerpc builds on FreeBSD.

Chris Johns chrisj at rtems.org
Mon Nov 28 23:32:30 UTC 2016


On 29/11/2016 09:58, Joel Sherrill wrote:
> On Mon, Nov 28, 2016 at 3:49 PM, Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
>
>     On 27/11/2016 11:36, Joel Sherrill wrote:
>
>         On Nov 26, 2016 6:48 PM, "Chris Johns" <chrisj at rtems.org
>         <mailto:chrisj at rtems.org>
>         <mailto:chrisj at rtems.org <mailto:chrisj at rtems.org>>> wrote:
>           >
>           > On 26/11/16 4:02 am, Joel Sherrill wrote:
>           > > This has had great support from the gdb developers.
>           >
>           > Yes the turn around time for this fix was excellent.
>           >
>           > >
>           > > Did any of the other targets show an issue?
>           > >
>           >
>           > I do not know. I have built sparc tools with the patch. I do
>         not know if
>           > it was also broken.
>
>         This was a build error so we need to build all the tools on
>         FreeBSD to
>         check.
>
>
>     I built 4.12/rtems-all on FreeBSD and the following failed:
>
>       epiphany-rtems4.12-gdb-7.8.1-x86_64-freebsd10.3-1
>       m32c-rtems4.12-gdb-7.9-x86_64-freebsd10.3-1
>       mips-rtems4.12-gcc-6-20161110-newlib-2.4.0.20161025-x86_64-freebsd10.3-1
>       mipstx39-rtems4.12-gdb-7.9-x86_64-freebsd10.3-1
>
>     The issues are:
>
>       epiphany-rtems4.12-gdb:
>       m32c-rtems4.12-gdb-7.9:
>       mipstx39-rtems4.12-gdb-7.9:
>         - libiconv issue
>
> I don't recall this one.
>

I suspect libiconv support needs a path or a library for some versions. 
The complication is iconv support changed with FreeBSD v10. This means 
the generic gdb build recipe may need help to be taught how to do this.

>       mips-rtems4.12-gcc-6-20161110-newlib-2.4.0.20161025:
>        - BSD shell issue in the expansion of the multilibs.
>
> We have emailed/filed/discussed this before with the GCC folks.
> The resolution was to use GNU sed.

Yes I remember.

> They were not willing to
> rewrite the t-* fragment to use BSD sed and GNU sed.

This is an unfortunate situation and it creates a negative feeling 
towards the gcc project. I would like to know if the cause is the result 
of a non-standards based feature in the GNU sed.

> Unless we find a sed expert, this is the solution.

It is not sed I had the problem with, it was the expected output. It 
requires knowledge of the expected MIUPS mult-libs. Plus I found the gcc 
build system with this stuff difficult to debug and see what the issue 
actually is.

>           > > I think this got applied to the 7.12 branch and master, right?
>           >
>           > Sorry, I do not know. I think this patch should be pushed
>         until a
>           > release with the fix is available. Ok to push?
>
>         I thought they put it on both but we need the patch so push what is
>         needed for 7.12.
>
>
>     They may have however I am not sure what you are asking.
>
> RTEMS has to use 7.12 as is with what patches we need. When 7.12.1 is
> out, we should jump to that.

Yes, however it is not clear to me if you are saying wait for that or 
can this patch be pushed? I do not think I have seen a clear OK to push, 
I may have missed it.

Chris



More information about the devel mailing list