Conflict when modifying newlib/openrisc to work for RTEMS

[Gedare Bloom]

On Wed, Mar 19, 2014 at 11:56 AM, Hesham Moustafa
<heshamelmatary at gmail.com> wrote:
>
>
>
> On Wed, Mar 19, 2014 at 5:04 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>
>> On Wed, Mar 19, 2014 at 2:00 AM, Hesham Moustafa
>> <heshamelmatary at gmail.com> wrote:
>> >
>> >
>> >
>> > On Wed, Mar 19, 2014 at 3:33 AM, Hesham Moustafa
>> > <heshamelmatary at gmail.com>
>> > wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Tue, Mar 18, 2014 at 8:26 PM, Joel Sherrill
>> >> <joel.sherrill at oarcorp.com>
>> >> wrote:
>> >>>
>> >>>
>> >>> On 3/18/2014 1:07 PM, Hesham Moustafa wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I am working on modifying or1k newlib port to be built for RTEMS.
>> >>> Building and installing
>> >>> newlib with --target=or1k-elf is done successfully, however, when I
>> >>> try
>> >>> to build newlib
>> >>> with --target=or1k-rtems4.11 I got conflict error.
>> >>>
>> >>> part of this error is
>> >>> "sys/rtems/crt0.c:72:22: error: conflicting types for 'read'"
>> >>>
>> >>> Hmmm... how old is there newlib?
>> >>>
>> >> I think their toolchain depends on newlib-2.0.0, but I have generated
>> >> patches
>> >>  to work with newlib-2.1.0.
>> >>>
>> >>> What's the prototype for read() versus unistd.h (or whereever it turns
>> >>> out to
>> >>> be prototyped)?
>> >>>
>> >> in newlib/libc/include/sys/unistd.h
>> >>
>> >> _READ_WRITE_RETURN_TYPE _EXFUN(read, (int __fd, void *__buf, size_t
>> >> __nbyte ));
>> >> _READ_WRITE_RETURN_TYPE _EXFUN(write, (int __fd, const void *__buf,
>> >> size_t
>> >> __nbyte ));
>> >>
>> > It seems like the problem was about ssize_t.
>> > I was able to work around this error by replacing return type of read
>> > from
>> > ssize_t to int.
>> > Not sure if this is the correct action to do or not, but I am not sure
>> > where
>> > to redefine
>> > ssize_t for or1k target.
>> You'll need to fix the or1k target's definition of ssize_t, not hack
>> unistd.h.
>>
> I did not hack unitstd.h, instead I changed the return type of read
> prototype at
> sys/rtems/crt0.c to int instead of ssize_t. is that acceptable ?
Probably not. You should avoid making RTEMS code cater to the missing
feature in some specific target, eg or1k here. Other RTEMS toolchains
define ssize_t correctly for this read prototype, so the toolchain you
provide for or1k also should.

>>
>> >>
>> >> and write function which conflicts too.
>> >>>
>> >>> It may also be possible that the or1k port doesn't have the underlying
>> >>> type
>> >>>
>> >>> definitions complete or correct.
>> >>>
>> >>> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html
>> >>>
>> >>> isn't the latest but read() requires ssize_t and size_t to be
>> >>> correctly
>> >>> and
>> >>> consistently defined for a target.
>> >>>
>> >>> You may end up having to reproduce the compile of crt0.c by hand and
>> >>> change the -c to a -E .. changing the output file.. and see what
>> >>> really
>> >>> is being preprocessed
>> >>>
>> >> I did that exactly and I found out that both read and write are
>> >> prototyped
>> >> as
>> >>
>> >> int read (int __fd, void *__buf, size_t __nbyte );
>> >> int write (int __fd, const void *__buf, size_t __nbyte );
>> >>
>> >> Also there is another syntax error at crt0.c
>> >>
>> >>
>> >> "../../../../../../../newlib-2.1.0-or1k/newlib/libc/sys/rtems/crt0.c:74:37:
>> >> error: expected ')' before '*' token
>> >>  RTEMS_STUB(int, sigfillset(sigset_t *set), { return -1; })"
>> >>
>> >> When I checked the output of -E I found out the following prototype :
>> >> int rtems_stub_sigfillset(sigset_t *set) { return -1; }; int
>> >> (*(sigset_t
>> >> *set) = ~(0), 0) { return -1; }
>> >>
>> > For this error I checked the -E output file and found out that :
>> > int rtems_stub_sigfillset(sigset_t *set) { return -1; }; is translated
>> > to >
>> > int (*(sigset_t *set) = ~(0), 0) { return -1; }
>> >>
>> >> and
>> >> typedef unsigned long sigset_t;
>> >> is out there.
>> >>
>> >> (I did not apply newlib-sys-signal-20130532.diff patch, yet, at the RSB
>> >> which
>> >>  do nothing with this error)
>> >>>
>> >>> or1k/newlib port implements some stuff at libgloss (including
>> >>> or1k/crt0.S)
>> >>>
>> >>> rtems uses nothing in libgloss.
>> >>>
>> >>> I just use --target=or1k-xxx --prefix=xxx as configuration options for
>> >>> newlib.
>> >>>
>> >>> The RTEMS builds take more. Check rtems-source-builder. Also if you
>> >>> are
>> >>> not building or1k-rtems tools including binutils and gcc+newlib
>> >>> together
>> >>> at the same time, it may be causing issues.
>> >>
>> >> For RSB, I can only see that newlib is linked into gcc directory and
>> >> then
>> >> gcc is built with
>> >> --with-newlib option (what am I missing ?)
>> >>
>> >> binutils (or1k-rtems4.11-*) is installed
>> >> and exported at prefix location. The process which I make is
>> >> 1- Build and install patched binutils-2.24 for RTEMS [successful]
>> >> 2- Build and install bootstrap patched gcc-4.8.2 [successful]
>> >> 3- Build and install patched newlib-2.1.0 [stuck here]
>> >> 4- Build and install patched gcc-4.8.2 with newlib
>> >>
>> >> Again, this process works fine with --target=or1k-elf and I am able to
>> >> compile simple
>> >> hello world program, it only conflicts at the previous 3rd point when
>> >> targeting
>> >> or1k-rtems4.11.
>> >>>
>> >>>
>> >>> Thanks,
>> >>> Hesham
>> >>>
>> >>>
>> >>> --
>> >>> 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
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > rtems-devel mailing list
>> > rtems-devel at rtems.org
>> > http://www.rtems.org/mailman/listinfo/rtems-devel
>> >
>
>