Re: PATCH: ARMV7M support

[Mark Mitchell <mark at codesourcery dot com>]

Shaun Jackman wrote:
> 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...

A lot of your questions relate to the combination of RDI and bare-metal
support.  This combination does make sense, as shown in my original
patch.  I will explain.

There are currently two ways in which requesting RDI support affects the
library.  The first is that crt0 uses RDI to set up the stack, heap,
command-line, etc.  The second is that the system call layer use RDI to
implement open, read, write, etc.

Now, consider an environment in which you are building code to run on a
target board, from flash.  You can't use the RDI crt0 because you want
to be able to boot the board without a debugger connected.  However, you
might want to have some debugging routines that, when you are connected
by the debugger, can do file I/O.  So, you can boot the board, and,
then, connect with the debugger and call "print_status()" and have it
use "printf" to print some messages on your terminal, say.  So, you do
want the RDI system calls.

The RDI macro definition in crt0.S do not apply just to crt0; they are
global defines that apply to the entire ARM support library.  So, if you
find it bothersome to have both ARM_RDI_MONITOR and _ARM_BARE_METAL
defined in crt0, we would want to adjust the Makefiles so that
ARM_RDI_MONITOR was only defined for the system calls, but not for crt0.

This is all further complicated by the fact that for ARM these bits are
both in newlib and in libgloss, and that newlib builds crt0.o itself.  I
would prefer to incorporate these changes, and then work on the
transition to a pure libgloss solution.

> Is the reason for exporting _angel_swi simply so that the end-user can
> call it? 

No, the reason for having a definition in swi.c is that GCC's inline
extension for C requires that a definition be available somewhere in
case GCC doesn't inline the function.  We could not have swi.c, and just
count on GCC inlining the function everywhere, but that would break a
-O0 build of the library.

> If so, does it make sense to call this function syscall(2)?

I don't have an opinion about that.  I'm happy to make that change if
you feel it best.

> 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.

I think we should avoid making the patch more complicated by tackling
this at the same time.  In addition to the approach you suggest, we
could also just drop RDP support.  It's already been dropped from GDB,
because nobody could find anything that still spoke RDP.  (In fact, even
RDI has been officially abandoned by ARM -- but there is a lot of RDI
hardware out there, and the GDB simulator supports RDI semihosting.)

> 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.

Yes, we could have a #error if none of ARM_RDP_MONITOR, ARM_RDI_MONITOR,
or _ARM_BARE_METAL are defined.  However, as above, I think we should
allow the combination of the first two, with the third.

Once I hear back from you, I will prepare a new version with the changes
you've requested.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713