[PATCH 00/14] Removal of or32/openrisc and introduction of or1k

[Joel Sherrill]

On 4/23/2014 3:38 PM, Hesham Moustafa wrote:
> On Wed, Apr 23, 2014 at 10:19 PM, Christian Svensson <christian at cmd.nu> wrote:
>> On Wed, Apr 23, 2014 at 9:12 PM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>> Is gcc close then?
>> Close to merging - not really. There is interest and momentum but the
>> effort hasn't begun.
>> Close to being fully functional - I would say so, bugs are rare and
>> it's only now when I'm porting the whole Debian distribution we
>> discover some obscure bugs.
>>
>>> From a very practical viewpoint, the only requirement to porting
>>> RTEMS is a functional gdb for the target. The target name and
>>> cleanliness isn't that important.
>> Bare metal GDB should be available as far as I understand.
>>
>>> OTOH, there will be rtems tweaks to gcc to add the or1k-rtems target.
>>> So it is more critical to get merged.
>> Worst case, we do track our own GCC called or1k-gcc, so merging with
>> that will ensure that it will be upstreamed in the future.
> One issue, building gcc for RTEMS will have to discard some libraries
> that are linked by default (like or1ksim) in or1k-gcc when compiling
> programs, I think that would be a conflict when thinking of merging
> gcc-rtems patch with or1k-gcc (unless there is a way to make the
> default linking process conditional to the target).
I don't think this is a problem. We normally change some of the linking
behavior. CPU-rtems starts with CPU-elf and overrides the defines
that we need to.

Plus as much as we would like to get rid of them, the bsp_specs
give a final override of some items.

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