This is the mail archive of the newlib@sourceware.org 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


On 3/31/06, Mark Mitchell <mark@codesourcery.com> wrote:
> Here is the bare-metal/dependency bit.  In this patch, _ARM_BARE_METAL
> is only defined if neither RDP or RDI support is available, but my
> expectation is that "something else" (configure, libgloss, etc.) will
> provide an option to define _ARM_BARE_METAL even when RDI support is
> available, so that (as in my original patch) you can have RDI support
> for semihosted system calls without relying on it from crt0.

Does this mean that one could compile a rdimon-crt0.o that is actually
compiled as _ARM_BARE_METAL? This seems a bit confusing. If a bare
metal crt0 is desired in conjunction with a RDI libgloss, perhaps a
linker script could specify...
	CRT0=bare-crt0.o
	LIBGLOSS=librdimon.a
This seems like a special case though.

> 2006-03-23  Mark Mitchell  <mark@codesourcery.com>
>
>         * libc/sys/arm/Makefile.am (extra_objs): Add _exit.o _nmi_isr.o
>         _fault_isr.o swi.o.
>         * libc/sys/arm/Makefile.in: Regenerated.
>         * libc/sys/arm/_exit.c: New file.
>         * libc/sys/arm/_fault_isr.c: Likewise.
>         * libc/sys/arm/_nmi_isr.c: Likewise.

These _xxx_isr.c files are ARMv7M specific and not needed for this patch.

>         * libc/sys/arm/swi.c: Likewise.

Is the reason for exporting _angel_swi simply so that the end-user can
call it? If so, does it make sense to call this function syscall(2)?
It might be a bit of a stretch naming this non-UNIX system call
interface thus, but it seems appropriate.

Looking over syscalls.c just now, it looks as though a lot of ifdef
pain could be avoided if syscall(SYS_write, ...) abstracted out the
minor calling convention differences between RDI's
AngelSWI_Reason_Write and RDP's SWI_Write.

>         * libc/sys/arm/crt0.S (_ARM_BARE_METAL): Define it, if not
>         using RDI or RDP.

Rather than _ARM_BARE_METAL being an implicit default, could
Makefile.in specify -D_ARM_BARE_METAL when compiling for bare-crt0.o
et al? The implicit default should be an #error message.

>         (start): Don't call monitor functions when _ARM_BARE_METAL is
>         defined.  Do not call
>         initialise_monitor_handles.
>         * libc/sys/arm/swi.h (_angel_swi): New function.

I like moving _angel_swi to swi.h to facilitate moving the individual
system calls out of syscalls.c into their own object files, allowing
the user to override system calls in a standard way. I like this much
better than __atribute__((weak)).

>         * libc/sys/arm/syscalls.c (_exit): Remove.
>         (do_angelSWI): Replace with _angel_swi.
>         (CHECK_INIT): Remove.
>         (remap_handle): Call initialise_monitor_handles.
>         (__arm_monitor_handles_lock): New variable.
>         (initialise_monitor_handles): Make sure to run only once.

Good stuff.

> *************** change_back:
> *** 281,291 ****
>         .word   __bss_end__
>   #ifdef __USES_INITFINI__
>   .Lfini:
>         .word   FUNCTION(_fini)
>   #endif
> ! #ifdef ARM_RDI_MONITOR
>   .LC30:
>         .word   CommandLine
>         .word   255
>
>   /*  Workspace for Angel calls.  */
> --- 285,295 ----
>         .word   __bss_end__
>   #ifdef __USES_INITFINI__
>   .Lfini:
>         .word   FUNCTION(_fini)
>   #endif
> ! #if defined(ARM_RDI_MONITOR) && !defined(_ARM_BARE_METAL)
>   .LC30:
>         .word   CommandLine
>         .word   255
>
>   /*  Workspace for Angel calls.  */

I am not so sure how sane it is to allow defining both ARM_RDI_MONITOR
and _ARM_BARE_METAL. These should be mutually exclusive, in my mind.

All around good work. Sorry for the extended delay in my reply.

Cheers,
Shaun

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