This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: ARMV7M support

Hello Mark,

On 3/23/06, Mark Mitchell <> wrote:
> This patch adds support for ARM V7M bare metal hardware to Newlib.
> Here are the changes:

Can you seperate the bare-metal and dependency (_exit and stdio)
component from the ARMv7M componenet of the patch? Non-ARMv7M targets
also benefit from your bare-metal/dependency work. I found the patch
difficult to read with the two matters mixed.

> 1. A new configure option --enable-newlib-arm-v7m.  When this option
>    is in effect, crt0.S does not make use of RDI to get the stack
>    pointer, or make any other RDI calls during startup.  That
>    eliminates access to the command-line, etc., but it also makes it
>    possible to use crt0.o without semihosting support.

Rather than a configure option, I'd prefer to see the bare-metal
support implemented as a libgloss/arm target, joining the ranks of
RDI, RDP, and RedBoot.

> 3. Avoids calling initialise_monitor_handlers from _start.  That
>    avoids pulling in all of syscalls.c into every program, and, since
>    syscalls.c depends on RDI, avoids pulling in RDI support.  Instead,
>    For reasons I don't understand, initialise_monitor_handles setup
>    stdio.  I don't see why that is required, and removing that avoids
>    pulling in stdio for a program using _open.
> 4. Factors _exit out into a separate file.  Every program needs _exit,
>    but not every program needs _open, etc.  We could further factor

I'm a big fan of avoid unnecessary dependencies.

> If this is approved, I'll commit it to libgloss too, unless explicitly
> told not to do so.

newlib/libc/sys/arm/ is out of sync with libgloss/arm/. You might have
a little trouble applying your patch. I'd like to see libc/sys/arm
permanently removed and --disable-newlib-supplied-syscalls become the
default. Is this possible, Jeff?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]