Re: [ECOS] Redboot and builtin functions

[Bart Veer <bartv at redhat dot com>]

>>>>> "Fabrice" == Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:

    Fabrice> About builtins functions, memcpy, memset ...

    Fabrice> I've seen that memset and memcpy are defined and
    Fabrice> implemented in multiple places.

    Fabrice> One of this place is generic-stub.c where a comment says
    Fabrice> that the stub can't use the same memcpy and memset than
    Fabrice> the rest (I can't see really why but why not..)

Already answered by others. Note that generic-stub.c came from the gdb
source tree and was not written from scratch by the eCos team.

    Fabrice> Another place is the libc (the string part to be more
    Fabrice> precise) where they are implemented with a weak
    Fabrice> attribute.

There is also the possibility that e.g. an architectural HAL package
might implement an optimized version for a specific cpu. AFAIK we
don't do that yet for any platform, but we have at least some of the
required infrastructure in place.

    Fabrice> Last place I saw is in redboot, but only for memset,
    Fabrice> memcpy is not implemted here... (why almost all the
    Fabrice> strings functions but memcpy?)

Same reason as for generic-stub.c, I don't know why memcpy() is
missing here. Possibly an oversight, unnoticed because so far memcpy()
has not been needed here.

    Fabrice> And there is the builtins too.

    Fabrice> So there are 4 implementations, but the one in redboot
    Fabrice> does not have the same declarations than the one in the
    Fabrice> eCos libc. I do not know for sure what the builtins
    Fabrice> declaration is (is there an include file for the
    Fabrice> builtins?) but I think they conform to the ISO standard,
    Fabrice> and so I guess are the same as the eCos libc.

    Fabrice> So, a few questions:

    Fabrice> 1/ Do the builtins are intented to be used at all in
    Fabrice> eCos? (if not, it lacks a -fno-builtin in the 386 target)

Yes. However my understanding is that the compiler may not support all
the builtins on all targets. Even when a builtin is implemented for a
given target it will not apply in all cases. For example in the case
of memcpy() the compiler might only generate inline code if it knows
about source and destination alignments, otherwise it would invoke the
function. An inlined memcpy() which can cope with all possible cases
involves a non-trivial amount of code, so using such a builtin
everywhere would lead to code bloat.

Also the function must be available at all times so that code can take
its address and pass a function pointer somewhere else. That would be
unusual for e.g. memcpy(), but legal.

    Fabrice> 2/ Why RedBoot doesn't/can't use the string functions
    Fabrice> defined in the libc ? Or the the builtins ?

Answered by others. 

    Fabrice> 3/ Which memcpy/memset the common ethernet support and
    Fabrice> ethernet drivers are supposed to use ?

The builtins if the compiler believes that is the right choice given
the target processor and its knowledge about e.g. data alignment.

Otherwise the RedBoot ones if the ethernet drivers are being used
inside RedBoot (I think).

Otherwise the ones in libc - unless there is an alternative
implementation in e.g. the architectural HAL

    Fabrice> 4/ When builtins are used by gcc, when does it use the
    Fabrice> user-defined version of memcpy/memset ?

See above.

Bart Veer // eCos net maintainer