Porting GCJ

[Joel Sherrill]

If you are looking at this for Google Summer of Code, I probably didn't
really given you much help.  If that is your goal, then let's take a 
different
view.

Consider RTEMS GCC Support as a broader project. This has multiple
areas that can be worked on. These are in no particular order but areas
that need attention.

+ Thread Local Storage support: This is something you need to support
    on a per architecture basis which impacts multiple languages. I recall
    Sebastian added it for a couple of targets but don't know the overall
    status.
+ Improved test results:Test failures need to be  reviewed and issues
   addressed. Many times, tests are NA or simply not correctly structured
    for *-rtems* targets. Sometimes, they indicate bugs we need to address.
   I know FORTRAN RTEMS results  are very good but a pattern matching
   issue on the formatted output tests results in hundreds of spurious
   failures. Neither myself nor Tobias Burnss  has had time to run this 
down.
+ Improvements to RTEMS GCC test scripts: Automatically comparing
    new results versus baselined results is needed.
+ Run glibc tests on newlib for *-rtems*: There is apparently a way
    to do this. I have never done it. We need to do it and have results.
    Again, baseline, deviations, etc. are important.
+ Secondary language refresh: Ensure GCJ, Ada, Go, FORTRAN, and
    Objective-C (1) build and (2) have reasonable test results. (1) is
    because as time goes by, general patches sometimes accidentally
    break *-rtems* targets. (2) is because failures need to be identified
    and addressed.

There is a related project to this which I jokingly refer to as the
"Summer of Simulators" which is aimed to identify the state of
all simulators supported by RTEMS, ensure they work with Eclipse,
verify current simulator versions work, fix issues, push patches
upstream, etc.. Basically bring a level of rigor to our management
of simulator versions and patches. And fix issues as you find them.

Sometimes a big project is a collection of smaller, seemingly
unrelated tasks which achieve a large goal. What I described
above for GCC, newlib, and the simulators are those.

--joel

On 4/4/2013 8:45 AM, Joel Sherrill wrote:
> On 4/4/2013 5:03 AM, Bucher Fabio wrote:
>> Hi
>>
>> I would like to port GCJ. I can see on the wiki page this work is completet for i386 architecture. So if i use this architecture, is there any work to do to use gcj? If yes, what do i have to do?
> The status of gcj is not checked on a regular basis but the instructions
> for building it are captured in the scripts in rtems-testing/gcc.
>
> Architectures which work for gcj have libffi support. Those that don't
> need at least that to be functional.
>> Thank you and best regards
>> Fabio Bucher
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>


-- 
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