Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29611 > unrolled thread

Making more of the C standard library mandatory for freestanding implementations

Back to article view | Back to comp.arch.embedded

Contents

  Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-06 18:19 +0200
    Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-06 16:47 +0000
      Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-06 19:16 +0200
        Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-06 18:10 +0000
          Re: Making more of the C standard library mandatory for freestanding implementations James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-06 15:10 -0400
            Re: Making more of the C standard library mandatory for freestanding implementations Richard Damon <Richard@Damon-Family.org> - 2020-05-06 16:08 -0400
              Re: Making more of the C standard library mandatory for freestanding implementations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-06 13:22 -0700
                Re: Making more of the C standard library mandatory for freestanding implementations Richard Damon <Richard@Damon-Family.org> - 2020-05-06 22:29 -0400
                  Re: Making more of the C standard library mandatory for freestanding implementations David Brown <david.brown@hesbynett.no> - 2020-05-07 15:43 +0200
              Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-06 22:36 +0200
                Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-06 20:57 +0000
                Re: Making more of the C standard library mandatory for freestanding implementations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-05-06 23:25 +0200
                  Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-06 21:34 +0000
                    Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-07 10:17 +0200
                      Re: Making more of the C standard library mandatory for freestanding implementations Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-05-07 18:45 +0300
                  Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-07 10:16 +0200
                    Re: Making more of the C standard library mandatory for freestanding implementations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2020-05-07 21:39 +0200
                      Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-07 21:44 +0200
                        Re: Making more of the C standard library mandatory for freestanding implementations Paul Rubin <no.email@nospam.invalid> - 2020-05-07 12:54 -0700
            Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-06 22:34 +0200
              Re: Making more of the C standard library mandatory for freestanding implementations upsidedown@downunder.com - 2020-05-07 09:13 +0300
              Re: Making more of the C standard library mandatory for freestanding implementations Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-05-07 18:47 +0300
                Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-07 15:51 +0000
                  Re: Making more of the C standard library mandatory for freestanding implementations Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-05-08 10:09 +0300
          Re: Making more of the C standard library mandatory for freestanding implementations Stefan Reuther <stefan.news@arcor.de> - 2020-05-07 18:00 +0200
            Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-07 17:17 +0000
              Re: Making more of the C standard library mandatory for freestanding implementations David Brown <david.brown@hesbynett.no> - 2020-05-07 20:23 +0200
              Re: Making more of the C standard library mandatory for freestanding implementations Stefan Reuther <stefan.news@arcor.de> - 2020-05-08 17:33 +0200
                Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-08 15:56 +0000
                  Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-08 20:31 +0200
                    Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-08 18:53 +0000
                      Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-08 21:32 +0200
                        Re: Making more of the C standard library mandatory for freestanding implementations David Brown <david.brown@hesbynett.no> - 2020-05-09 00:13 +0200
                          Re: Making more of the C standard library mandatory for freestanding implementations Richard Damon <Richard@Damon-Family.org> - 2020-05-08 18:45 -0400
                            Re: Making more of the C standard library mandatory for freestanding implementations Grant Edwards <invalid@invalid.invalid> - 2020-05-08 22:59 +0000
                              Re: Making more of the C standard library mandatory for freestanding implementations Richard Damon <Richard@Damon-Family.org> - 2020-05-09 08:29 -0400
                            Re: Making more of the C standard library mandatory for freestanding implementations David Brown <david.brown@hesbynett.no> - 2020-05-09 16:10 +0200
                              Re: Making more of the C standard library mandatory for freestanding implementations Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-05-09 20:15 +0300
                                Re: Making more of the C standard library mandatory for freestanding implementations David Brown <david.brown@hesbynett.no> - 2020-05-10 12:37 +0200
                  Re: Making more of the C standard library mandatory for freestanding implementations Stefan Reuther <stefan.news@arcor.de> - 2020-05-09 09:52 +0200
      Re: Making more of the C standard library mandatory for freestanding implementations Florian Weimer <fw@deneb.enyo.de> - 2020-05-08 18:48 +0200
        Re: Making more of the C standard library mandatory for freestanding implementations Andrew Smallshaw <andrews@sdf.org> - 2020-05-08 17:01 +0000
          Re: Making more of the C standard library mandatory for freestanding implementations Philipp Klaus Krause <pkk@spth.de> - 2020-05-08 20:05 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#29624

On Wed, 6 May 2020 22:34:16 +0200, Philipp Klaus Krause <pkk@spth.de>
wrote:

>Am 06.05.20 um 21:10 schrieb James Kuyper:
>> On 5/6/20 2:10 PM, Grant Edwards wrote:
>>> On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:
>>>> Am 06.05.20 um 18:47 schrieb Grant Edwards:
>>>>>>
>>>>>> Do you see any reason those could not be provided on some C
>>>>>> implementation?
>>>>>
>>>>> Memory size.
>>>>
>>>> Could you elaborate?
>>>>
>>>> I do not see a problem there: If the programmer doesn't use e.g.
>>>> memcpy(), no memcpy() will be linked in, so memory size would not be
>>>> affected.
>>>
>>> Would that be required by the spec?
>> 
>> No, but it might be required by the marketplace. […]
>
>While compilers exist, that cannot remove unused functions from
>non-library user code (though such removal is now a common feature), I
>do not know of any compilers that would link in the whole standard
>library. All implementations known to me will only link in the used
>parts of the standard library.

The standard practice for at least half a century has been to put only
a single library function into a source file and compile each module
separately.

In the most primitive form just add the names of the required library
object files at the end of the linker command line.

A more elaborate library systems put these object files into a single
library file, builds a symbol table for global functions defined in
each library module. When the linker has linked the user program and
there are still undefined external references, scan the library symbol
table to find which module defines the required global symbol. Then
seek() to the start of the module and read it in. If there are new
undefined symbols, repeat the library symbol table scan.

[toc] | [prev] | [next] | [standalone]

#29629

On 6.5.20 23:34, Philipp Klaus Krause wrote:
> Am 06.05.20 um 21:10 schrieb James Kuyper:
>> On 5/6/20 2:10 PM, Grant Edwards wrote:
>>> On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:
>>>> Am 06.05.20 um 18:47 schrieb Grant Edwards:
>>>>>>
>>>>>> Do you see any reason those could not be provided on some C
>>>>>> implementation?
>>>>>
>>>>> Memory size.
>>>>
>>>> Could you elaborate?
>>>>
>>>> I do not see a problem there: If the programmer doesn't use e.g.
>>>> memcpy(), no memcpy() will be linked in, so memory size would not be
>>>> affected.
>>>
>>> Would that be required by the spec?
>>
>> No, but it might be required by the marketplace. […]
> 
> While compilers exist, that cannot remove unused functions from
> non-library user code (though such removal is now a common feature), I
> do not know of any compilers that would link in the whole standard
> library. All implementations known to me will only link in the used
> parts of the standard library.
> 
> Philipp
> 

The shared/dynamic libraries contain all the functions with
their entry points listed separately.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#29630

On 2020-05-07, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:

> The shared/dynamic libraries contain all the functions with
> their entry points listed separately.

I've never seen a freestanding target that had shared/dynamic
libraries.  All of the freestanding targets I've ever worked with ran
as a single statically linked binary executable.

--
Grant

[toc] | [prev] | [next] | [standalone]

#29637

On 7.5.20 18:51, Grant Edwards wrote:
> On 2020-05-07, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
> 
>> The shared/dynamic libraries contain all the functions with
>> their entry points listed separately.
> 
> I've never seen a freestanding target that had shared/dynamic
> libraries.  All of the freestanding targets I've ever worked with ran
> as a single statically linked binary executable.
> 
> --
> Grant


Neither have I. Just mentioned it to keep the shared libraries
out of the discussion.

I even use the options in GNU toolset to drop unused functions
at linking stage.

For bare metal, I have needed to recompile the newlib-arm
with size optimization (-Os) to keep the resulting binary
at a minimum size.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#29631

Am 06.05.2020 um 20:10 schrieb Grant Edwards:
> On 2020-05-06, Philipp Klaus Krause <pkk@spth.de> wrote:
>> Am 06.05.20 um 18:47 schrieb Grant Edwards:
>>>> Do you see any reason those could not be provided on some C
>>>> implementation?
>>>
>>> Memory size.
>>
>> Could you elaborate?
>>
>> I do not see a problem there: If the programmer doesn't use e.g.
>> memcpy(), no memcpy() will be linked in, so memory size would not be
>> affected.
> 
> Would that be required by the spec?

I'm actually pretty surprised that memcpy is NOT required part of a
freestanding implementation (hadn't looked for a while...) because
compilers actually call memcpy even if the programmer does not call it,
for structure assignment.

https://gcc.godbolt.org/z/wGNKDZ

In addition to that, compilers call a bunch of other little helper
functions (e.g. long long division), so they will have a way to pull
functions out of a library if needed.


  Stefan

[toc] | [prev] | [next] | [standalone]

#29632

On 2020-05-07, Stefan Reuther <stefan.news@arcor.de> wrote:

> I'm actually pretty surprised that memcpy is NOT required part of a
> freestanding implementation (hadn't looked for a while...) because
> compilers actually call memcpy even if the programmer does not call
> it, for structure assignment.
>
> https://gcc.godbolt.org/z/wGNKDZ

Yea, that's an acknowleged and documented "feature" of GCC:

  https://gcc.gnu.org/onlinedocs/gcc/Standards.html

See the penultimate paragraph in section 2.1.

> In addition to that, compilers call a bunch of other little helper
> functions (e.g. long long division), so they will have a way to pull
> functions out of a library if needed.

I don't think anybody claimed that there are no low-level compiler
support library functions required when linking in "freestanding"
mode.  Those are typically reserved for use by the compiler and not
visible to the user.

[toc] | [prev] | [next] | [standalone]

#29633

On 07/05/2020 19:17, Grant Edwards wrote:
> On 2020-05-07, Stefan Reuther <stefan.news@arcor.de> wrote:
> 
>> I'm actually pretty surprised that memcpy is NOT required part of a
>> freestanding implementation (hadn't looked for a while...) because
>> compilers actually call memcpy even if the programmer does not call
>> it, for structure assignment.
>>
>> https://gcc.godbolt.org/z/wGNKDZ
> 
> Yea, that's an acknowleged and documented "feature" of GCC:
> 
>    https://gcc.gnu.org/onlinedocs/gcc/Standards.html
> 
> See the penultimate paragraph in section 2.1.
> 
>> In addition to that, compilers call a bunch of other little helper
>> functions (e.g. long long division), so they will have a way to pull
>> functions out of a library if needed.
> 
> I don't think anybody claimed that there are no low-level compiler
> support library functions required when linking in "freestanding"
> mode.  Those are typically reserved for use by the compiler and not
> visible to the user.
> 

Yes.  That can include things like multiplication and division functions 
for processors that don't support it in hardware, and especially 
software floating point.  These things are often referred to as 
"language support libraries" and are part of the compiler, rather than 
part of the C library.

[toc] | [prev] | [next] | [standalone]

#29638

Am 07.05.2020 um 19:17 schrieb Grant Edwards:
> On 2020-05-07, Stefan Reuther <stefan.news@arcor.de> wrote:
>> I'm actually pretty surprised that memcpy is NOT required part of a
>> freestanding implementation (hadn't looked for a while...) because
>> compilers actually call memcpy even if the programmer does not call
>> it, for structure assignment.
>>
>> https://gcc.godbolt.org/z/wGNKDZ
> 
> Yea, that's an acknowleged and documented "feature" of GCC:
> 
>   https://gcc.gnu.org/onlinedocs/gcc/Standards.html
> 
> See the penultimate paragraph in section 2.1.

I get similar code from ARM msvc, x86-64 clang, and armv8-a clang, so
gcc is not an outlier here.

>> In addition to that, compilers call a bunch of other little helper
>> functions (e.g. long long division), so they will have a way to pull
>> functions out of a library if needed.
> 
> I don't think anybody claimed that there are no low-level compiler
> support library functions required when linking in "freestanding"
> mode.  Those are typically reserved for use by the compiler and not
> visible to the user.

The point I tried to make is that there's little reason to worry that
there is a compiler that links in all of libc if memcpy is used, because
compilers have a means of linking these functions as needed.

TL;DR: I don't see any technical roadblocks that would prevent requiring
more utility functions for a freestanding implementation.


  Stefan

[toc] | [prev] | [next] | [standalone]

#29639

On 2020-05-08, Stefan Reuther <stefan.news@arcor.de> wrote:

> The point I tried to make is that there's little reason to worry
> that there is a compiler that links in all of libc if memcpy is
> used, because compilers have a means of linking these functions as
> needed.
>
> TL;DR: I don't see any technical roadblocks that would prevent
> requiring more utility functions for a freestanding implementation.

What's the benefit of requiring extra stuff for a freestanding
iplementation?

--
Grant

[toc] | [prev] | [next] | [standalone]

#29643

Am 08.05.20 um 17:56 schrieb Grant Edwards:
> 
> What's the benefit of requiring extra stuff for a freestanding
> iplementation?

Not requiring the users of freestanding implementations to roll their
own implementations of that extra stuff.

[toc] | [prev] | [next] | [standalone]

#29644

On 2020-05-08, Philipp Klaus Krause <pkk@spth.de> wrote:
> Am 08.05.20 um 17:56 schrieb Grant Edwards:
>> 
>> What's the benefit of requiring extra stuff for a freestanding
>> iplementation?
>
> Not requiring the users of freestanding implementations to roll their
> own implementations of that extra stuff.

That's what you expect when you decide to use a freestanding
implmentation. If I want to use an the off-the shelf memcpy()
function, why not just link with libc?

--
Grant

[toc] | [prev] | [next] | [standalone]

#29645

Am 08.05.20 um 20:53 schrieb Grant Edwards:
> On 2020-05-08, Philipp Klaus Krause <pkk@spth.de> wrote:
>> Am 08.05.20 um 17:56 schrieb Grant Edwards:
>>>
>>> What's the benefit of requiring extra stuff for a freestanding
>>> iplementation?
>>
>> Not requiring the users of freestanding implementations to roll their
>> own implementations of that extra stuff.
> 
> That's what you expect when you decide to use a freestanding
> implmentation. If I want to use an the off-the shelf memcpy()
> function, why not just link with libc?

Which libc?
A freestanding implementation's libc might not have memcpy(). A
third-party libc might not be available for my target device.

[toc] | [prev] | [next] | [standalone]

#29646

On 08/05/2020 21:32, Philipp Klaus Krause wrote:
> Am 08.05.20 um 20:53 schrieb Grant Edwards:
>> On 2020-05-08, Philipp Klaus Krause <pkk@spth.de> wrote:
>>> Am 08.05.20 um 17:56 schrieb Grant Edwards:
>>>>
>>>> What's the benefit of requiring extra stuff for a freestanding
>>>> iplementation?
>>>
>>> Not requiring the users of freestanding implementations to roll their
>>> own implementations of that extra stuff.
>>
>> That's what you expect when you decide to use a freestanding
>> implmentation. If I want to use an the off-the shelf memcpy()
>> function, why not just link with libc?
> 
> Which libc?
> A freestanding implementation's libc might not have memcpy(). A
> third-party libc might not be available for my target device.
> 

You are worrying about a non-existent problem.  /All/ C toolchains come 
with memcpy() and similar functions - certainly anything that is 
realistic to include in a subset of the C library for freestanding 
toolchains.

People /never/ have to write their own memcpy() - but in freestanding 
systems, they can if they want to.  (Toolchains invariably come with 
memcpy, but that doesn't mean they come with a memcpy implementation 
that is ideal for your needs.)

[toc] | [prev] | [next] | [standalone]

#29647

On 5/8/20 6:13 PM, David Brown wrote:
> On 08/05/2020 21:32, Philipp Klaus Krause wrote:
>> Am 08.05.20 um 20:53 schrieb Grant Edwards:
>>> On 2020-05-08, Philipp Klaus Krause <pkk@spth.de> wrote:
>>>> Am 08.05.20 um 17:56 schrieb Grant Edwards:
>>>>>
>>>>> What's the benefit of requiring extra stuff for a freestanding
>>>>> iplementation?
>>>>
>>>> Not requiring the users of freestanding implementations to roll their
>>>> own implementations of that extra stuff.
>>>
>>> That's what you expect when you decide to use a freestanding
>>> implmentation. If I want to use an the off-the shelf memcpy()
>>> function, why not just link with libc?
>>
>> Which libc?
>> A freestanding implementation's libc might not have memcpy(). A
>> third-party libc might not be available for my target device.
>>
> 
> You are worrying about a non-existent problem.  /All/ C toolchains come
> with memcpy() and similar functions - certainly anything that is
> realistic to include in a subset of the C library for freestanding
> toolchains.
> 
> People /never/ have to write their own memcpy() - but in freestanding
> systems, they can if they want to.  (Toolchains invariably come with
> memcpy, but that doesn't mean they come with a memcpy implementation
> that is ideal for your needs.)
> 

But you can't call your memcpy with the name memcpy because that name is
RESERVED with external linkage (even if the implementation doesn't
support it as a freestanding implementation).

Yes, if the implementation doesn't support a function, you can probably
get away with defining one of your own by that name, but it isn't
guaranteed that it will work.

[toc] | [prev] | [next] | [standalone]

#29648

On 2020-05-08, Richard Damon <Richard@Damon-Family.org> wrote:

> But you can't call your memcpy with the name memcpy because that name is
> RESERVED with external linkage (even if the implementation doesn't
> support it as a freestanding implementation).

Why should I be forbidden from providing my own implementation of
memcpy()?  What does such a ban accomplish?

> Yes, if the implementation doesn't support a function, you can
> probably get away with defining one of your own by that name, but it
> isn't guaranteed that it will work.

It should be.

--
Grant

[toc] | [prev] | [next] | [standalone]

#29650

On 5/8/20 6:59 PM, Grant Edwards wrote:
> On 2020-05-08, Richard Damon <Richard@Damon-Family.org> wrote:
> 
>> But you can't call your memcpy with the name memcpy because that name is
>> RESERVED with external linkage (even if the implementation doesn't
>> support it as a freestanding implementation).
> 
> Why should I be forbidden from providing my own implementation of
> memcpy()?  What does such a ban accomplish?
> 
>> Yes, if the implementation doesn't support a function, you can
>> probably get away with defining one of your own by that name, but it
>> isn't guaranteed that it will work.
> 
> It should be.
> 
> --
> Grant
> 
> 

Because of the wording of the Standard. ALL external names (like
functions) defined in ANY header (independent of you using them) are
reserved for the implementation with external linkage. The Standard
doesn't make an exception for things not supported due to being a
free-standing implementation.

Part of the issue is that for a free-standing implementation you don't
know (and can't really test for) that the function isn't implemented.
One thing that was brought up is that maybe it would make sense to have
what is and isn't defined be part of the required documentation.

[toc] | [prev] | [next] | [standalone]

#29651

On 09/05/2020 00:45, Richard Damon wrote:
> On 5/8/20 6:13 PM, David Brown wrote:
>> On 08/05/2020 21:32, Philipp Klaus Krause wrote:
>>> Am 08.05.20 um 20:53 schrieb Grant Edwards:
>>>> On 2020-05-08, Philipp Klaus Krause <pkk@spth.de> wrote:
>>>>> Am 08.05.20 um 17:56 schrieb Grant Edwards:
>>>>>>
>>>>>> What's the benefit of requiring extra stuff for a freestanding
>>>>>> iplementation?
>>>>>
>>>>> Not requiring the users of freestanding implementations to roll their
>>>>> own implementations of that extra stuff.
>>>>
>>>> That's what you expect when you decide to use a freestanding
>>>> implmentation. If I want to use an the off-the shelf memcpy()
>>>> function, why not just link with libc?
>>>
>>> Which libc?
>>> A freestanding implementation's libc might not have memcpy(). A
>>> third-party libc might not be available for my target device.
>>>
>>
>> You are worrying about a non-existent problem.  /All/ C toolchains come
>> with memcpy() and similar functions - certainly anything that is
>> realistic to include in a subset of the C library for freestanding
>> toolchains.
>>
>> People /never/ have to write their own memcpy() - but in freestanding
>> systems, they can if they want to.  (Toolchains invariably come with
>> memcpy, but that doesn't mean they come with a memcpy implementation
>> that is ideal for your needs.)
>>
> 
> But you can't call your memcpy with the name memcpy because that name is
> RESERVED with external linkage (even if the implementation doesn't
> support it as a freestanding implementation).
> 
> Yes, if the implementation doesn't support a function, you can probably
> get away with defining one of your own by that name, but it isn't
> guaranteed that it will work.
> 

Again, there is a matter of practical realities.  Trying to define your 
own memcpy() with that same name can be risky - it's the kind of 
function that implementations treat in special ways (such as the 
compiler replacing it with inline loops).  It is definitely a bad idea 
to make your own definitions for a function like that with semantics 
that differ from the standard version.

The standard linking process used by most implementations (but not 
required by the standards) means that if you have a definition of a 
function in your C code, that will take precedence over implementations 
in the library.  It is not unusual in embedded programming to use this 
fact to have empty stubs for functions like "exit" or "atexit" as a way 
of avoiding too much extra code being pulled in from the standard library.

This is all highly implementation-specific, of course.

[toc] | [prev] | [next] | [standalone]

#29652

On 9.5.20 17:10, David Brown wrote:
> On 09/05/2020 00:45, Richard Damon wrote:
>> On 5/8/20 6:13 PM, David Brown wrote:
>>> On 08/05/2020 21:32, Philipp Klaus Krause wrote:
>>>> Am 08.05.20 um 20:53 schrieb Grant Edwards:
>>>>> On 2020-05-08, Philipp Klaus Krause <pkk@spth.de> wrote:
>>>>>> Am 08.05.20 um 17:56 schrieb Grant Edwards:
>>>>>>>
>>>>>>> What's the benefit of requiring extra stuff for a freestanding
>>>>>>> iplementation?
>>>>>>
>>>>>> Not requiring the users of freestanding implementations to roll their
>>>>>> own implementations of that extra stuff.
>>>>>
>>>>> That's what you expect when you decide to use a freestanding
>>>>> implmentation. If I want to use an the off-the shelf memcpy()
>>>>> function, why not just link with libc?
>>>>
>>>> Which libc?
>>>> A freestanding implementation's libc might not have memcpy(). A
>>>> third-party libc might not be available for my target device.
>>>>
>>>
>>> You are worrying about a non-existent problem.  /All/ C toolchains come
>>> with memcpy() and similar functions - certainly anything that is
>>> realistic to include in a subset of the C library for freestanding
>>> toolchains.
>>>
>>> People /never/ have to write their own memcpy() - but in freestanding
>>> systems, they can if they want to.  (Toolchains invariably come with
>>> memcpy, but that doesn't mean they come with a memcpy implementation
>>> that is ideal for your needs.)
>>>
>>
>> But you can't call your memcpy with the name memcpy because that name is
>> RESERVED with external linkage (even if the implementation doesn't
>> support it as a freestanding implementation).
>>
>> Yes, if the implementation doesn't support a function, you can probably
>> get away with defining one of your own by that name, but it isn't
>> guaranteed that it will work.
>>
> 
> Again, there is a matter of practical realities.  Trying to define your 
> own memcpy() with that same name can be risky - it's the kind of 
> function that implementations treat in special ways (such as the 
> compiler replacing it with inline loops).  It is definitely a bad idea 
> to make your own definitions for a function like that with semantics 
> that differ from the standard version.
> 
> The standard linking process used by most implementations (but not 
> required by the standards) means that if you have a definition of a 
> function in your C code, that will take precedence over implementations 
> in the library.  It is not unusual in embedded programming to use this 
> fact to have empty stubs for functions like "exit" or "atexit" as a way 
> of avoiding too much extra code being pulled in from the standard library.
> 
> This is all highly implementation-specific, of course.


There's good reason to make own implementation of e.g. memcpy() in a
small embedded system: The library functions often attempt to optimize
with larger than byte transfers, and the logic is far too long for small
memory. If the implementation is in a module loaded before the standard
library, it should override the library function. It is fully OK for the
compiler to replace it with macro loops, the code simply does not refer
to the library function at all, so the point is moot here.

exit(), atexit() and friends simply do not exist in a small embedded
system. The system runs forever or until power off.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#29653

On 09/05/2020 19:15, Tauno Voipio wrote:
> On 9.5.20 17:10, David Brown wrote:
>> On 09/05/2020 00:45, Richard Damon wrote:
>>> On 5/8/20 6:13 PM, David Brown wrote:
>>>> On 08/05/2020 21:32, Philipp Klaus Krause wrote:
>>>>> Am 08.05.20 um 20:53 schrieb Grant Edwards:
>>>>>> On 2020-05-08, Philipp Klaus Krause <pkk@spth.de> wrote:
>>>>>>> Am 08.05.20 um 17:56 schrieb Grant Edwards:
>>>>>>>>
>>>>>>>> What's the benefit of requiring extra stuff for a freestanding
>>>>>>>> iplementation?
>>>>>>>
>>>>>>> Not requiring the users of freestanding implementations to roll 
>>>>>>> their
>>>>>>> own implementations of that extra stuff.
>>>>>>
>>>>>> That's what you expect when you decide to use a freestanding
>>>>>> implmentation. If I want to use an the off-the shelf memcpy()
>>>>>> function, why not just link with libc?
>>>>>
>>>>> Which libc?
>>>>> A freestanding implementation's libc might not have memcpy(). A
>>>>> third-party libc might not be available for my target device.
>>>>>
>>>>
>>>> You are worrying about a non-existent problem.  /All/ C toolchains come
>>>> with memcpy() and similar functions - certainly anything that is
>>>> realistic to include in a subset of the C library for freestanding
>>>> toolchains.
>>>>
>>>> People /never/ have to write their own memcpy() - but in freestanding
>>>> systems, they can if they want to.  (Toolchains invariably come with
>>>> memcpy, but that doesn't mean they come with a memcpy implementation
>>>> that is ideal for your needs.)
>>>>
>>>
>>> But you can't call your memcpy with the name memcpy because that name is
>>> RESERVED with external linkage (even if the implementation doesn't
>>> support it as a freestanding implementation).
>>>
>>> Yes, if the implementation doesn't support a function, you can probably
>>> get away with defining one of your own by that name, but it isn't
>>> guaranteed that it will work.
>>>
>>
>> Again, there is a matter of practical realities.  Trying to define 
>> your own memcpy() with that same name can be risky - it's the kind of 
>> function that implementations treat in special ways (such as the 
>> compiler replacing it with inline loops).  It is definitely a bad idea 
>> to make your own definitions for a function like that with semantics 
>> that differ from the standard version.
>>
>> The standard linking process used by most implementations (but not 
>> required by the standards) means that if you have a definition of a 
>> function in your C code, that will take precedence over 
>> implementations in the library.  It is not unusual in embedded 
>> programming to use this fact to have empty stubs for functions like 
>> "exit" or "atexit" as a way of avoiding too much extra code being 
>> pulled in from the standard library.
>>
>> This is all highly implementation-specific, of course.
> 
> 
> There's good reason to make own implementation of e.g. memcpy() in a
> small embedded system: The library functions often attempt to optimize
> with larger than byte transfers, and the logic is far too long for small
> memory. If the implementation is in a module loaded before the standard
> library, it should override the library function. It is fully OK for the
> compiler to replace it with macro loops, the code simply does not refer
> to the library function at all, so the point is moot here.

Yes, agreed.  (But you should be aware that this only works if the 
implementation works the way you expect here.  In practice it is likely 
to be fine - I have not seen any exceptions.)

> 
> exit(), atexit() and friends simply do not exist in a small embedded
> system. The system runs forever or until power off.
> 

Indeed.  But sometimes these get linked in by other library functions, 
and you can get cascades of extra library code from using a seemingly 
innocent little utility function.  When you see your binary size 
suddenly much larger than you expect, the solution is sometimes to 
examine a map file with cross-references, figure out the root functions, 
and make stubs - as you say, functions like these ones will never be 
called, so leaving them empty is fine.

[toc] | [prev] | [next] | [standalone]

#29649

Am 08.05.2020 um 17:56 schrieb Grant Edwards:
> On 2020-05-08, Stefan Reuther <stefan.news@arcor.de> wrote:
>> The point I tried to make is that there's little reason to worry
>> that there is a compiler that links in all of libc if memcpy is
>> used, because compilers have a means of linking these functions as
>> needed.
>>
>> TL;DR: I don't see any technical roadblocks that would prevent
>> requiring more utility functions for a freestanding implementation.
> 
> What's the benefit of requiring extra stuff for a freestanding
> iplementation?

Making the "freestanding" subset more useful.

It probably depends on what one considers the mission of a freestanding
implementation. I had considered the primary objective to be: run
without any operating system support. Things like 'memcpy' or 'strlen',
even 'sprintf', can be implemented in pure C without any operating
system support (needing just a little implementation knowledge like "how
to stringify a pointer" in 'sprintf', or "how to detect overlap" in
'memmove'). Therefore, adding those functions does not constrain the
environment such an implementation could run on.

If one instead considers a freestanding implementation to be just a
portable assembler to turn logic into machine code and otherwise get out
of my way, leaving out 'memcpy' & friends is plausible.


  Stefan

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web