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

Mon Apr 28 16:32:32 UTC 2014

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.

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