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

[Joel Sherrill]

On Mon, Nov 28, 2016 at 5:32 PM, Chris Johns <chrisj at rtems.org> wrote:

> 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-f
>> reebsd10.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.


Ping the GCC Pr and see if Richard Sandiford can at least provide
example input and output.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097


>
>           > > 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.
>
>
Push it. :)


> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20161128/3eaf7902/attachment-0002.html>