Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset

[Hesham Moustafa]

On Mon, Apr 28, 2014 at 6:32 PM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
> On 4/28/2014 11:25 AM, Hesham Moustafa wrote:
>> Thanks! These patches really help. I've already reverted back to the
>> original read/write prototypes after defining __rtems__ and it works.
>> Now newlib works normally (with the non-GPL patch you provided before
>> and my modifications). The only issues I have to make some workarounds
>> for are related to some POSIX macros. i.e,
>>
>> NAME_MAX (at newlib/libc/sys/rtems/sys/dirent.h)
>> PATH_MAX (at newlib/libc/posix/collate.c)
>>  _POSIX2_RE_DUP_MAX (at newlib/libc/posix/utils.h)
>>
>> I got undefined macro errors for these three macros, thus, I had to
>> add some #ifndef XXX statements earlier at the container files, to get
>> over there errors.
> I suspect that was for not having __rtems__ defined.  Revert them
> and try. I don't see NAME_MAX hacked on in my source so you
> must not have them committed.
>
> Also there are some header files in sys/rtems. If those are not the
> ones installed, then the build still has problems. But I suspect that
> is OK no
>
> I used the patch on your github and you got my diff.
>
> FYI all of the code in newlib/libc/machine/or1k is totally completely
> unacceptable to newlib from a license perspective.  It is GPL v3 and
> totally unacceptable to RTEMS as well.
>
Yes I got that. By "the patch you provided" I mean this one [1]. I no
longer use the patch on my github account anymore. Soon, I will submit
the new newlib patch for review and to discuss about it.

[1] http://www.doc.ic.ac.uk/~jab00/or32-newlib/newlib-patch
> And besides, two of the three files in there don't believe in libc
> at all. So we need a BSD-ish licensed setjmp/longjmp.
>>
>> On Mon, Apr 28, 2014 at 6:02 PM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>> Hi
>>>
>>> I am not sure I got everything fixed but it should be a lot
>>> better now. See the attached diffs.
>>>
>>> + libgcc - patterns were in the wrong order and or1k*-*-rtems*
>>>    or1k*-*-* was before rtems stanza
>>> + config/or1k - moved elf.h to rtemself.h. There should be
>>>   a target OS independent config/or1k/elf.h
>>>   Also fixed or1k/rtemself.h so it defines CPP predefines
>>>   including __rtems__ which explains your compilation problem.
>>> + newlib/.../rtems/crt0 had wrong prototypes for write() and
>>>   read().
>>>
>>> These are diffs against the sources with your patches applied.
>>>
>>> Apply on top of yours.
>>>
>>> It is still building here after clobbering the tree and starting
>>> over so there may be more problems but this should be
>>> a good start. :)
>>>
>>> --joel
>>>
>>>
>>> On 4/27/2014 7:26 PM, Joel Sherrill wrote:
>>>> This is a bug in your gcc port. You need to ensure that __rtems__ is defined.
>>>>
>>>> See https://github.com/heshamelmatary/or1k-rtems/blob/master/patches/gcc-4.8.2-or1k-rtems.diff
>>>> around 220 and compare it to
>>>> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/rtems-eabi.h;h=4bdcf0d87ba68940f338f4de3b41b9bd7a47260f;hb=HEAD
>>>>
>>>> That defines __rtems__. Without that, the .h files in newlib don't get the right settings.
>>>> ________________________________________
>>>> From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] On Behalf Of Joel Sherrill [Joel.Sherrill at oarcorp.com]
>>>> Sent: Sunday, April 27, 2014 7:17 PM
>>>> To: Hesham Moustafa
>>>> Cc: rtems-devel at rtems.org
>>>> Subject: Re: Possible bug at newlib/libc/rtems/sys/crt0.c sigfillset
>>>>
>>>> On Apr 27, 2014 6:40 PM, Joel Sherrill <Joel.Sherrill at oarcorp.com> wrote:
>>>>> On Apr 27, 2014 5:12 PM, Hesham Moustafa <heshamelmatary at gmail.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> When I am trying to get newlib compiled while porting newlib to
>>>>>> rtems/or1k, I met an error that confused me. The error happens for me
>>>>>> with both: Ubuntu and Fedora. Also it arises when configuring and
>>>>>> building a standalone newlib library (with configure
>>>>>> --target=or1k-rtems4.11) or when building gcc with newlib (for the
>>>>>> same target). By commenting that line, newlib and gcc building process
>>>>>> works fine.
>>>>>>
>>>>>> The error is:
>>>>>>
>>>>>> "../../../../../../../gcc-4.8.2-or1k-rtems/newlib/libc/sys/rtems/crt0.c:74:37:
>>>>>> error: expected ‘)’ before ‘*’ token
>>>>>>  RTEMS_STUB(int, sigfillset(sigset_t *set), { return -1; })"
>>>>>>
>>>>>> By expanding the macros with -E option, I got the following expansion
>>>>>> for the corresponding function:
>>>>>>
>>>>>> int rtems_stub_sigfillset(sigset_t *set) { return -1; }; int
>>>>>> (*(sigset_t *set) = ~(0), 0) { return -1; }
>>>>>>
>>>>>> Does that make sense?
>>>>>>
>>>>>> I searched for anyone that happened to have the same problem and I
>>>>>> found this link [1] related to compiling rtems/newlib for microblaze
>>>>> This is a new architecture for RTEMS+newlib combination. I recall that there is a configure script near the top of newlib and it needs an entry for thus target. Or a pattern needs adjusting to distinguish or1k*-*-* from the RTEMS variant.
>>>> This can also be because the path through signal.h is skipping something based on or1k.
>>>>
>>>> What source are you using as base to modify? I need to clone all your source and try it myself.
>>>>
>>>>>> [1] http://sourceware.org/ml/newlib/2012/msg00529.html
>>>>>>
>>>>>> Regards,
>>>>>> Hesham
>>>>>>
>>>>>> _______________________________________________
>>>>>> rtems-devel mailing list
>>>>>> rtems-devel at rtems.org
>>>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>> --
>>> Joel Sherrill, Ph.D.             Director of Research & Development
>>> joel.sherrill at OARcorp.com        On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>> Support Available                (256) 722-9985
>>>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>