[incubator-nuttx] 01/03: sim/README: Mention macOS

[xi...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

xiaoxiang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-nuttx.git

commit 2f6d458bcfd0fa75378dc4119e16192b39ac2743
Author: YAMAMOTO Takashi <ya...@midokura.com>
AuthorDate: Fri Mar 27 15:43:47 2020 +0900

    sim/README: Mention macOS
---
 boards/sim/sim/sim/README.txt | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/boards/sim/sim/sim/README.txt b/boards/sim/sim/sim/README.txt
index a52e31b..4875d83 100644
--- a/boards/sim/sim/sim/README.txt
+++ b/boards/sim/sim/sim/README.txt
@@ -27,7 +27,7 @@ Description
 -----------
 This README file describes the contents of the build configurations available
 for the NuttX "sim" target.  The sim target is a NuttX port that runs as a
-user-space program under Linux or Cygwin.  It is a very "low fidelity"
+user-space program under Linux, Cygwin, or macOS.  It is a very "low fidelity"
 embedded system simulation:  This environment does not support any kind of
 asynchronous events -- there are nothing like interrupts in this context.
 Therefore, there can be no pre-empting events.
@@ -84,8 +84,9 @@ graphical front-end to GDB:
    gdb> b user_start
    gdb> r
 
-NOTE:  This above steps work fine on both Linux and Cygwin.  On Cygwin, you
-will need to start the Cygwin-X server before running ddd.
+NOTE:  This above steps work fine on Linux, Cygwin, and macOS.
+On Cygwin, you will need to start the Cygwin-X server before running ddd.
+On macOS, it's probably easier to use lldb instead of gdb.
 
 Issues
 ^^^^^^
@@ -121,11 +122,11 @@ NuttX heap.  The memory management model is exactly the same in the simulation
 as in a real, target system.  This is good because this produces a higher
 fidelity simulation.
 
-However, when the simulation calls into Linux/Cygwin libraries, it will still
+However, when the simulation calls into the host OS libraries, it will still
 use these small simulation stacks.  This happens, for example, when you call
 into the system to get and put characters to the console window or when you
 make X11 calls into the system.  The programming model within those libraries
-will assume a Linux/Cygwin environment where the stack size grows dynamically
+will assume the host OS environment where the stack size grows dynamically
 and not the small, limited stacks of a deeply embedded system.
 
 As a consequence, those system libraries may allocate large data structures on
@@ -156,9 +157,9 @@ The simulation build is a two pass build:
      and then linked with nuttx.rel to generate the simulation program.
 
 NuttX is a POSIX compliant RTOS and is normally built on a POSIX compliant
-host environment (like Linux or Cygwin).  As a result, the same symbols are
-exported by both the NuttX domain and the host domain.  How can we keep them
-separate?
+host environment (like Linux, Cygwin, or macOS).  As a result, the same
+symbols are exported by both the NuttX domain and the host domain.  How can
+we keep them separate?
 
 This is done using the special file nuttx-name.dat.  This file just contains a
 mapping of original function names to new function names.  For example, the