On 4/23/2014 3:38 PM, Hesham Moustafa wrote: > On Wed, Apr 23, 2014 at 10:19 PM, Christian Svensson <christ...@cmd.nu> wrote: >> On Wed, Apr 23, 2014 at 9:12 PM, Joel Sherrill >> <joel.sherr...@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.sherr...@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@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
