Hi Peter
Ping.
[DJ is on vacation, so I am standing in for him...]
Perhaps moving the cio-enabled nosys to a libcio.a? Then we'd need a
-mcio option to gcc to enable it, but could default to doing the
generic nosys thing...
I like that approach; it makes clear that the system interface
On Mon, Sep 22, 2014 at 2:17 AM, Nicholas Clifton ni...@redhat.com wrote:
Hi Peter
Ping.
[DJ is on vacation, so I am standing in for him...]
Thanks for responding.
Perhaps moving the cio-enabled nosys to a libcio.a? Then we'd need a
-mcio option to gcc to enable it, but could default
Hi Peter,
gcc: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01809.html
newlib: https://sourceware.org/ml/newlib/2014/msg00465.html
I'd appreciate it if you or DJ would shepherd these through: I don't
think anybody on either list is likely to merge them otherwise.
Both patches have now been
On Mon, Sep 22, 2014 at 10:49 AM, Nicholas Clifton ni...@redhat.com wrote:
Hi Peter,
gcc: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01809.html
newlib: https://sourceware.org/ml/newlib/2014/msg00465.html
I'd appreciate it if you or DJ would shepherd these through: I don't
think anybody
It's not really feasible to extract those changes and apply them to a
non-bundled source directory since the base version isn't exactly GCC
4.9.1.If you or TI could provide information on whether those
patches are likely to get refactored and merged upstream, and any
timeline information
On Mon, Sep 22, 2014 at 11:40 AM, DJ Delorie d...@redhat.com wrote:
It's not really feasible to extract those changes and apply them to a
non-bundled source directory since the base version isn't exactly GCC
4.9.1.If you or TI could provide information on whether those
patches are likely
Ping.
On Thu, Jun 5, 2014 at 5:55 PM, Peter Bigot big...@acm.org wrote:
On Thu, Jun 5, 2014 at 4:48 PM, DJ Delorie d...@redhat.com wrote:
The reason msp430 is different is because CIO *can* be used on real
hardware, to communicate through a hardware debugger or emulator pod.
Perhaps moving
Starting a new thread since this is off-topic for MSP430 simulator in gdb.
The discussion is how to take advantage of newlib's libc
infrastructure while replacing the system interface that is by default
provided by libgloss: i.e. implementations of
read()/write()/sbrk()/gettimeofday() and other
The reason msp430 is different is because CIO *can* be used on real
hardware, to communicate through a hardware debugger or emulator pod.
Perhaps moving the cio-enabled nosys to a libcio.a? Then we'd need a
-mcio option to gcc to enable it, but could default to doing the
generic nosys thing...
On Thu, Jun 5, 2014 at 4:48 PM, DJ Delorie d...@redhat.com wrote:
The reason msp430 is different is because CIO *can* be used on real
hardware, to communicate through a hardware debugger or emulator pod.
Perhaps moving the cio-enabled nosys to a libcio.a? Then we'd need a
-mcio option to
10 matches
Mail list logo
