[ECOS] Redboot and builtin functions

[ECOS] Redboot and builtin functions

[Fabrice Gautier]

Hi,

WHen building redboot I've the followings warnings:

packages/redboot/current/src/misc_funs.c:69: warning: conflicting types for
built-in function `strcpy'
packages/redboot/current/src/misc_funs.c:127: warning: conflicting types for
built-in function `memcmp'
packages/redboot/current/src/misc_funs.c:138: warning: conflicting types for
built-in function `memset'

I can get rid of them if I build with -fno-builtin, but then i've some
"implicit declaration" warnings.

Thanks,

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] Redboot and builtin functions

[Bart Veer]

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

    <snip>
    Fabrice> Same problem (not the same prototype), and that would
    Fabrice> means add a dependency to libc for the driver. Or a
    Fabrice> dependency on a macro (like IMPLEMENT_MEMSET) provided by
    Fabrice> libc and redboot.

    Fabrice> What I want is to get rid of these warnings. And I'm not
    Fabrice> sure the what the correct solution is.

I don't know all the issues related to RedBoot internals so this has
to be Gary's call. However if RedBoot is defining prototypes for e.g.
memcpy() that are not in accordance with the C standard then I would
consider that to be a bug.

Bart Veer // eCos net maintainer

RE: [ECOS] Redboot and builtin functions

[Fabrice Gautier]

> -----Original Message-----
> From: Bart Veer [ mailto:bartv@redhat.com ]
> Sent: Thursday, October 19, 2000 5:01 AM
> To: Fabrice_Gautier@sdesigns.com
> Cc: ecos-discuss@sourceware.cygnus.com
> Subject: Re: [ECOS] Redboot and builtin functions
> 
> 
> >>>>> "Fabrice" == Fabrice Gautier 
> <Fabrice_Gautier@sdesigns.com> writes:

>     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.
 
But the problem is that Redboot functions does not have the same declaration
than builtins or libc ones.
 
>     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

Same problem (not the same prototype), and that would means add a dependency
to libc for the driver. Or a dependency on a macro (like IMPLEMENT_MEMSET)
provided by libc and redboot.

What I want is to get rid of these warnings. And I'm not sure the what the
correct solution is.

Thanks
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] Redboot and builtin functions

[Bart Veer]

>>>>> "Gary" == Gary Thomas <gthomas@redhat.com> writes:

    Gary> On 19-Oct-2000 Fabrice Gautier wrote:

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

    Gary> RedBoot was originally targetted to be built with only the
    Gary> HAL package. In particular, I had wanted to leave out even
    Gary> INFRA. Sadly, there are many dependencies on INFRA, even in
    Gary> HAL. In fact, you should think of HAL as being layered in
    Gary> INFRA.

    Gary> That's the reason for the [private] copies of the various
    Gary> functions in RedBoot.

    Gary> 'memcpy' turns out to just be an oversight.

For the record, having absolutely everything depend on INFRA was a
deliberate decision early on in the design process. It means that
there will always be assertion macros and the like available, and
hence there is no excuse for writing code without assertions. This
should probably be documented somewhere.

Bart Veer // eCos net maintainer

RE: [ECOS] Redboot and builtin functions

[Gary Thomas]

On 19-Oct-2000 Fabrice Gautier wrote:
> Last place I saw is in redboot, but only for memset, memcpy is not implemted
> here... (why almost all the strings functions but memcpy?)
> 

RedBoot was originally targetted to be built with only the HAL package.
In particular, I had wanted to leave out even INFRA.  Sadly, there are
many dependencies on INFRA, even in HAL.  In fact, you should think of
HAL as being layered in INFRA.

That's the reason for the [private] copies of the various functions in RedBoot.

'memcpy' turns out to just be an oversight.  

Re: [ECOS] Redboot and builtin functions

[Jonathan Larmour]

Jesper Skov wrote:
> 
> >>>>> "Fabrice" == Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:
> 
> Fabrice> One of this place is generic-stub.c where a comment says that
> Fabrice> the stub can't use the same memcpy and memset than the rest
> Fabrice> (I can't see really why but why not..)
> 
> Because while you are debugging the application, you may be setting
> breakpoints at various places and single-stepping your way through
> memcpy and memset. If the stub used the same functions as the
> application it would crash, hang, or format the disks on your
> neighbor's WinDOS machine.
> 
> Basically, the stub needs to be fully detached from the
> application/eCos to function properly.

That's fair enough for stubs inside the application. It doesn't apply to
redboot though - the memcpy() etc. it links in will be a separate instance
to the ones in the app.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Redboot and builtin functions

[Bart Veer]

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

Re: [ECOS] Redboot and builtin functions

[Jesper Skov]

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

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

Because while you are debugging the application, you may be setting
breakpoints at various places and single-stepping your way through
memcpy and memset. If the stub used the same functions as the
application it would crash, hang, or format the disks on your
neighbor's WinDOS machine.

Basically, the stub needs to be fully detached from the
application/eCos to function properly.

Jesper

Re: [ECOS] Redboot and builtin functions

[Andrew Lunn]

> About builtins functions, memcpy, memset ...
> 
> I've seen that memset and memcpy are defined and implemented in multiple
> places.
> 
> One of this place is generic-stub.c where a comment says that the stub can't
> use the same memcpy and memset than the rest (I can't see really why but why
> not..) 

We had a problem where we needed to single step through memcpy when we
had some data corruption going in. The gdb stub itself uses memcpy, so
you end with a break point in the code handling the break point and it
all dies horribly. The static definitions of memcpy in the stub make
sure the stub has its own memcpy functions which will never get a
break point in it and you can then debug the globel memcpy functions.

        Andrew

RE: [ECOS] Redboot and builtin functions

[Fabrice Gautier]

Hi,

About builtins functions, memcpy, memset ...

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

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

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

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

And there is the builtins too.

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

So, a few questions:

1/ Do the builtins are intented to be used at all in eCos? (if not, it lacks
a -fno-builtin in the 386 target)
2/ Why RedBoot doesn't/can't use the string functions defined in the libc ?
Or the the builtins ?
3/ Which memcpy/memset the common ethernet support and ethernet drivers are
supposed to use ?
4/ When builtins are used by gcc, when does it use the user-defined version
of memcpy/memset ?

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 







> -----Original Message-----
> From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> Sent: Wednesday, October 18, 2000 11:24 AM
> To: Ecos-List (E-mail)
> Subject: [ECOS] Redboot and builtin functions
> 
> 
> Hi,
> 
> WHen building redboot I've the followings warnings:
> 
> packages/redboot/current/src/misc_funs.c:69: warning: 
> conflicting types for
> built-in function `strcpy'
> packages/redboot/current/src/misc_funs.c:127: warning: 
> conflicting types for
> built-in function `memcmp'
> packages/redboot/current/src/misc_funs.c:138: warning: 
> conflicting types for
> built-in function `memset'
> 
> I can get rid of them if I build with -fno-builtin, but then i've some
> "implicit declaration" warnings.
> 
> Thanks,
> 
> -- 
> Fabrice Gautier
> fabrice_gautier@sdesigns.com 
> 

RE: [ECOS] Redboot and builtin functions

[Fabrice Gautier]

By the way, why doesn't redboot use the memset and memcpy functions
implemtend in the infra package?

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

> -----Original Message-----
> From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> Sent: Wednesday, October 18, 2000 11:24 AM
> To: Ecos-List (E-mail)
> Subject: [ECOS] Redboot and builtin functions
> 
> 
> Hi,
> 
> WHen building redboot I've the followings warnings:
> 
> packages/redboot/current/src/misc_funs.c:69: warning: 
> conflicting types for
> built-in function `strcpy'
> packages/redboot/current/src/misc_funs.c:127: warning: 
> conflicting types for
> built-in function `memcmp'
> packages/redboot/current/src/misc_funs.c:138: warning: 
> conflicting types for
> built-in function `memset'
> 
> I can get rid of them if I build with -fno-builtin, but then i've some
> "implicit declaration" warnings.
> 
> Thanks,
> 
> -- 
> Fabrice Gautier
> fabrice_gautier@sdesigns.com 
>