[PATCH] Add support for TIRTOS

[Kapania, Ashish]

Hi Jeff,

Thanks for your feedback. I will submit the change in src/config.sub directly
to the GNU config project as per the MAINTAINERS document. I have updated my
earlier patch file to remove the "may_supply_syscalls" check and split it into
2 separate patches. As per the MAINTAINERS doc any global maintainer can
approve changes to src/configure.ac so I am submitting the patch here.

List of patches (attached):
tirtos_support.patch01 (contains newlib/ and libgloss/ changes)
tirtos_support.patch02 (contains src/configure.ac change)

I would like to confirm that the changes in my patches were made by me and I
have my employer's consent to contribute these changes to the newlib project.

Best,
Ashish

-----Original Message-----
From: Jeff Johnston [mailto:jjohnstn@redhat.com] 
Sent: Wednesday, April 02, 2014 10:15 AM
To: Kapania, Ashish
Cc: newlib@sourceware.org
Subject: Re: [PATCH] Add support for TIRTOS

Hi Ashish,

The top-level files in src need to be submitted to a different mailing list.
Check out the top-level src/MAINTAINERS file for details.  

I have a few comments about the newlib/libgloss bits.

You're logic in checking the may_supply_syscalls flag is incorrect.  The may_supply_sycalls option is designed to allow older sys dirs to supply the low-level syscalls that libgloss is meant to supply.  The libc/sys/arm directory is one of those.  The problem with the sys dir supplying syscalls is it builds these into newlib itself and thus changing board models or using a simulator can't be done by simple linker usage.
In your case, you are overriding the sys_dir directory so libc/sys/arm won't even be used and thus there is no reason to set the ARM_RDI_MONITOR flag.  You do, however, need to set the have_crt0 flag to "no".  This is because your sys directory does not create a crt0.o file which the build will expect to copy up the chain.  I would have expected your build to fail without you specifying --disable-newlib-may-supply-syscalls.

Can you also please note whether you have written 100% of the code and whether you have permission from your employer to donate this code to newlib?

Thanks,

-- Jeff J.

----- Original Message -----
> From: "Ashish Kapania" <akapania@ti.com>
> To: newlib@sourceware.org
> Sent: Friday, March 28, 2014 9:52:44 PM
> Subject: [PATCH] Add support for TIRTOS
> 
> Hi All,
> 
> This is a request to apply the attached patch to newlib. This patch 
> intends to add TIRTOS support 
> (http://processors.wiki.ti.com/index.php/TI-RTOS) in newlib.
> 
> I have not included a diff for the generated files. If that is 
> required please let me know and I can share an updated patch.
> 
> Thanks,
> Ashish
> 
> ChangeLog:
> 
> From 6d77663313dbe484a0447028bed227b2d881eaac Mon Sep 17 00:00:00 2001
> From: Ashish Kapania <akapania@ti.com>
> Date: Fri, 28 Mar 2014 18:32:04 -0700
> Subject: [PATCH] Add support for TIRTOS
> 
> ---
> ChangeLog                                 |   5 ++ config.sub                                
> |   4 +- configure.ac                              |   2 +- 
> libgloss/ChangeLog                        |   5 ++ 
> libgloss/arm/configure.in                 |   2 +- newlib/ChangeLog                          
> |  12 ++++ newlib/configure.host                     |  20 ++++++ 
> newlib/libc/stdio/local.h                 |   2 +- 
> newlib/libc/sys/configure.in              |   1 + 
> newlib/libc/sys/tirtos/Makefile.am        |  16 +++++ 
> newlib/libc/sys/tirtos/configure.in       |  14 ++++ 
> newlib/libc/sys/tirtos/include/sys/lock.h | 109
> ++++++++++++++++++++++++++++++
> newlib/libc/sys/tirtos/lock.c             |  92 
> +++++++++++++++++++++++++
> 13 files changed, 279 insertions(+), 5 deletions(-) create mode 100644 
> newlib/libc/sys/tirtos/Makefile.am
> create mode 100644 newlib/libc/sys/tirtos/configure.in
> create mode 100644 newlib/libc/sys/tirtos/include/sys/lock.h
> create mode 100644 newlib/libc/sys/tirtos/lock.c
>                                                       
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tirtos_support.patch01
Type: application/octet-stream
Size: 12772 bytes
Desc: tirtos_support.patch01
URL: <http://sourceware.org/pipermail/newlib/attachments/20140402/bd5c2221/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tirtos_support.patch02
Type: application/octet-stream
Size: 1196 bytes
Desc: tirtos_support.patch02
URL: <http://sourceware.org/pipermail/newlib/attachments/20140402/bd5c2221/attachment-0001.obj>