Re: Patch to allow strlen expander to fail

Re: Patch to allow strlen expander to fail

[Phil Edwards]

Toon Moene wrotes:
> Martin v. Loewis wrote:
>
> > I can't see how linking libgcc helps; it does not provide a version of
> > memcpy, either. GCC currently assumes that the programs it generates
> > will be linked with the system's standard C library; that assumption
> > is incorrect for a freestanding environment. 
>
> Well, that's great, but the C Standard only asserts that there are two
> execution environments defined - it doesn't say how a particular
> compiler discerns whether it is compiling for one or the other
> environment.
>
> I think this can only be solved by having a compile time switch that
> makes clear which of the two environments one compiles for.  It's
> amazing to me that a compiler that's used so much in the embedded
> community, doesn't even _have_ -hosted and -freestanding options.

We're still talking about GCC, right?  Your wish has already been granted.
:-)  From the pages for 2.95.2:

#  `-fhosted'
#       Assert that compilation takes place in a hosted environment.  This
#       implies `-fbuiltin'.  A hosted environment is one in which the
#       entire standard library is available, and in which `main' has a
#       return type of `int'.  Examples are nearly everything except a
#       kernel.  This is equivalent to `-fno-freestanding'.
#  
#  `-ffreestanding'
#       Assert that compilation takes place in a freestanding environment.
#       This implies `-fno-builtin'.  A freestanding environment is one
#       in which the standard library may not exist, and program startup
#       may not necessarily be at `main'.  The most obvious example is an
#       OS kernel.  This is equivalent to `-fno-hosted'.

I couldn't tell you how those switches get used in the source, or what
they currently affect.


Luck++;
Phil

Re: Patch to allow strlen expander to fail

[Toon Moene]

Phil Edwards wrote:

> I wrote:

[ freestanding vs hosted execution environment in C ]

> > I think this can only be solved by having a compile time switch that
> > makes clear which of the two environments one compiles for.  It's
> > amazing to me that a compiler that's used so much in the embedded
> > community, doesn't even _have_ -hosted and -freestanding options.
> 
> We're still talking about GCC, right?  Your wish has already been granted.
> :-)  From the pages for 2.95.2:
> 
> #  `-fhosted'

> #  `-ffreestanding'

Yes, in Dutch we would call this "papier is geduldig"

> I couldn't tell you how those switches get used in the source, or what
> they currently affect.

Use grep - it helps !

% grep freestanding *.c
c-decl.c:  else if (!strcmp (p, "-fhosted") || !strcmp (p,
"-fno-freestanding"))
c-decl.c:  else if (!strcmp (p, "-ffreestanding") || !strcmp (p,
"-fno-hosted"))
c-decl.c:      /* We set this to 2 here, but 1 in -Wmain, so
-ffreestanding can turn
toplev.c:  { "-ffreestanding",
toplev.c:  { "-fno-freestanding", "" },

[ Ah, so it *has* them ]

% grep freestanding *.h
c-tree.h:/* Nonzero means environment is hosted (i.e., not freestanding)
*/
% view c-tree.h
[ ... ]
/* Nonzero means environment is hosted (i.e., not freestanding) */

extern int flag_hosted;
[ ... ]
% grep flag_hosted *.c
c-decl.c:int flag_hosted = 1;
c-decl.c:      flag_hosted = 1;
c-decl.c:      flag_hosted = 0;

That's all, folks !

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

... Slowly recovering from the Olympic Gardens ....

Re: Patch to allow strlen expander to fail

[Clinton Popetz]

On Tue, Mar 07, 2000 at 05:20:51PM -0500, Phil Edwards wrote:
 
> #  `-fhosted'
> #       Assert that compilation takes place in a hosted environment.  This
> #       implies `-fbuiltin'.  A hosted environment is one in which the
> #       entire standard library is available, and in which `main' has a
> #       return type of `int'.  Examples are nearly everything except a
> #       kernel.  This is equivalent to `-fno-freestanding'.
> #  
> #  `-ffreestanding'
> #       Assert that compilation takes place in a freestanding environment.
> #       This implies `-fno-builtin'.  A freestanding environment is one
> #       in which the standard library may not exist, and program startup
> #       may not necessarily be at `main'.  The most obvious example is an
> #       OS kernel.  This is equivalent to `-fno-hosted'.
> 
> I couldn't tell you how those switches get used in the source, or what
> they currently affect.

Except for setting -fbuiltin appropriately, they have no effect currently.  
(They set flag_hosted in c-decl.c, but nothing uses that flag.)

They were added here:

Sun Jan 19 15:05:42 1997  Peter Seebach  <seebs@solon.com>

        * c-decl.c (start_decl): Add code for -Wmain.
        (c_decode_option): Add -fhosted, -ffreestanding, and -Wmain.
        * toplev.c (lang_options): Likewise.
        * c-tree.h (warn_main, flag_hosted): New variables.


but never touched afterward.

					-Clint

Re: Patch to allow strlen expander to fail

[Toon Moene]

I wrote:

> [ freestanding vs hosted execution environment in C ]

> % grep flag_hosted *.c
> c-decl.c:int flag_hosted = 1;
> c-decl.c:      flag_hosted = 1;
> c-decl.c:      flag_hosted = 0;
> 
> That's all, folks !

I probably should go to sleep - flag_hosted == 0 implies flag_no_builtin
- so it should work correctly.  The Linux makefile(s) simply have to
specify -ffreestanding to get this to work correctly.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: Patch to allow strlen expander to fail

[Martin v. Loewis]

> I probably should go to sleep - flag_hosted == 0 implies flag_no_builtin
> - so it should work correctly.  The Linux makefile(s) simply have to
> specify -ffreestanding to get this to work correctly.

Not quite:

loewis 37 ( ~/tmp ) > cat a.c
struct X{
  long foo[16];
};

void docopy(struct X* a,struct X* b)
{
  *b=*a;
}

loewis 38 ( ~/tmp ) > gcc -v
Reading specs from gnu/lib/gcc-lib/sparc-sun-solaris2.5.1/2.96/specs
gcc version 2.96 20000228 (experimental)

loewis 39 ( ~/tmp ) > gcc -S -O2 -ffreestanding a.c

loewis 40 ( ~/tmp ) > cat a.s
        .file   "a.c"
gcc2_compiled.:
.section        ".text"
        .align 4
        .global docopy
        .type    docopy,#function
        .proc   020
docopy:
        !#PROLOGUE# 0
        save    %sp, -112, %sp
        !#PROLOGUE# 1
        mov     %i1, %o0
        mov     %i0, %o1
        call    memcpy, 0
        mov     64, %o2
        ret
        restore
.LLfe1:
        .size    docopy,.LLfe1-docopy
        .ident  "GCC: (GNU) 2.96 20000228 (experimental)"

so it generated a memcpy call even with -ffreestanding. This is
because of (what I consider) a bug in gcc, which emits a call to
memcpy even when asked not to. The technical reason is that
-fno-builtin only disables availability of inline-optimizations for
user memcpy calls - the memcpy call generated by the block mover is
hard-coded, and does not care about freestanding or not.

Regards,
Martin

Re: Patch to allow strlen expander to fail

[Toon Moene]

Martin v. Loewis wrote:

> I wrote:

> > I probably should go to sleep - flag_hosted == 0 implies flag_no_builtin
> > - so it should work correctly.  The Linux makefile(s) simply have to
> > specify -ffreestanding to get this to work correctly.

> Not quite:

[ .... example elided ... ]

> so it generated a memcpy call even with -ffreestanding. This is
> because of (what I consider) a bug in gcc, which emits a call to
> memcpy even when asked not to. The technical reason is that
> -fno-builtin only disables availability of inline-optimizations for
> user memcpy calls - the memcpy call generated by the block mover is
> hard-coded, and does not care about freestanding or not.

Bweh - I was afraid of that but couldn't find an example that showed the
problem.  Thanks for that.  AFAICS, my conclusion is yours: This means
that GCC doesn't support freestanding compilation correctly.

The block mover should be fixed in the sense that it uses memcpy only if
flag_hosted is true.  But I wouldn't be surprised if there were more
places in the compiler where this isn't handled correctly ...

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: Patch to allow strlen expander to fail

[Brian R. Gaeke]

And then spake Clinton Popetz, as follows:
> On Tue, Mar 07, 2000 at 05:20:51PM -0500, Phil Edwards wrote:
> > #  `-fhosted'
> > #       Assert that compilation takes place in a hosted environment.  This
> > #       implies `-fbuiltin'.  A hosted environment is one in which the
> > #       entire standard library is available, and in which `main' has a
> > #       return type of `int'.  Examples are nearly everything except a
> > #       kernel.  This is equivalent to `-fno-freestanding'.
> > #  `-ffreestanding'
> > #       Assert that compilation takes place in a freestanding environment.
> > #       This implies `-fno-builtin'.  A freestanding environment is one
> > #       in which the standard library may not exist, and program startup
> > #       may not necessarily be at `main'.  The most obvious example is an
> > #       OS kernel.  This is equivalent to `-fno-hosted'.

Additionally, I had sent in a bug report about -ffreestanding not
affecting gcc's normal behavior of trying to call hosted C-runtime
stuff from main() (__main(), etc) using egcs 1.1.1 targetting mips. I
found this behavior when trying to compile test cases for a MIPS virtual
machine simulator I was writing.  I still think this behavior is wrong.
I haven't tested to see whether it exists in the latest snaps, though
from the above discussion I am assuming things haven't changed much...
anyway, if people are going to be hacking on -ffreestanding, it's probably
a good loose end to tie up.

-Brian

-- 
Brian R. Gaeke, brg@sartre.dgate.ORG -- PGP/GPG gleefully accepted
"the iguana / in the petshop window on St Catherine Street / crested,
 royal-eyed, ruling / its kingdom of water-dish and sawdust / dreams of
 sawdust" - Margaret Atwood, "Dreams of the Animals"

Re: Patch to allow strlen expander to fail

[Jeffrey A Law]

  In message < 20000310090713.A20157@celes.dgate.ORG >you write:
  > And then spake Clinton Popetz, as follows:
  > > On Tue, Mar 07, 2000 at 05:20:51PM -0500, Phil Edwards wrote:
  > > > #  `-fhosted'
  > > > #       Assert that compilation takes place in a hosted environment.  T
  > his
  > > > #       implies `-fbuiltin'.  A hosted environment is one in which the
  > > > #       entire standard library is available, and in which `main' has a
  > > > #       return type of `int'.  Examples are nearly everything except a
  > > > #       kernel.  This is equivalent to `-fno-freestanding'.
  > > > #  `-ffreestanding'
  > > > #       Assert that compilation takes place in a freestanding environme
  > nt.
  > > > #       This implies `-fno-builtin'.  A freestanding environment is one
  > > > #       in which the standard library may not exist, and program startu
  > p
  > > > #       may not necessarily be at `main'.  The most obvious example is 
  > an
  > > > #       OS kernel.  This is equivalent to `-fno-hosted'.
  > 
  > Additionally, I had sent in a bug report about -ffreestanding not
  > affecting gcc's normal behavior of trying to call hosted C-runtime
  > stuff from main() (__main(), etc) using egcs 1.1.1 targetting mips. I
  > found this behavior when trying to compile test cases for a MIPS virtual
  > machine simulator I was writing.  I still think this behavior is wrong.
  > I haven't tested to see whether it exists in the latest snaps, though
  > from the above discussion I am assuming things haven't changed much...
  > anyway, if people are going to be hacking on -ffreestanding, it's probably
  > a good loose end to tie up.
The __main is not a hosted vs non-hosted issue -- the behavior of the
compiler is correct.  __main is critical for the proper behavior of ctors/dtors
which are 100% independent of the hosted vs non-hosted environment.

-ffreestanding does not and will not ever control the call to __main.

jeff

Re: Patch to allow strlen expander to fail

[Jamie Lokier]

Jeffrey A Law wrote:
> The __main is not a hosted vs non-hosted issue -- the behavior of the
> compiler is correct.  __main is critical for the proper behavior of
> ctors/dtors which are 100% independent of the hosted vs non-hosted
> environment.

Does the __main mechanism work at all for a freestanding environment?
Part of the definition of freestanding is that the program isn't
necessarily entered at main.

-- Jamie

Re: Patch to allow strlen expander to fail

[Toshiyasu Morita]

> 
> 
>   In message < 20000310090713.A20157@celes.dgate.ORG >you write:
>   > And then spake Clinton Popetz, as follows:
(stuff deleted)
>   > Additionally, I had sent in a bug report about -ffreestanding not
>   > affecting gcc's normal behavior of trying to call hosted C-runtime
>   > stuff from main() (__main(), etc) using egcs 1.1.1 targetting mips. I
>   > found this behavior when trying to compile test cases for a MIPS virtual
>   > machine simulator I was writing.  I still think this behavior is wrong.
>   > I haven't tested to see whether it exists in the latest snaps, though
>   > from the above discussion I am assuming things haven't changed much...
>   > anyway, if people are going to be hacking on -ffreestanding, it's probably
>   > a good loose end to tie up.
> The __main is not a hosted vs non-hosted issue -- the behavior of the
> compiler is correct.  __main is critical for the proper behavior of ctors/dtors
> which are 100% independent of the hosted vs non-hosted environment.
> 
> -ffreestanding does not and will not ever control the call to __main.
> 
> jeff
> 
> 

I have a patch which suppresses the call to __main in main...would other 
people be interested in this patch? If so, i can submit it for inclusion.

Toshi

Re: Patch to allow strlen expander to fail

[Toon Moene]

Martin v. Loewis wrote:

> I can't see how linking libgcc helps; it does not provide a version of
> memcpy, either. GCC currently assumes that the programs it generates
> will be linked with the system's standard C library; that assumption
> is incorrect for a freestanding environment. 

Well, that's great, but the C Standard only asserts that there are two
execution environments defined - it doesn't say how a particular
compiler discerns whether it is compiling for one or the other
environment.

I think this can only be solved by having a compile time switch that
makes clear which of the two environments one compiles for.  It's
amazing to me that a compiler that's used so much in the embedded
community, doesn't even _have_ -hosted and -freestanding options.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: Patch to allow strlen expander to fail

[Martin v. Loewis]

> The programmer can not and should not need to know the details of how that
> assignment is performed.  If they think they need control over that kind of
> implementation detail, then they're barking up the wrong tree.

With the current gcc, the programmer *must* know such details. If she
ignores it, the program won't link in the end unless she provides a
memcpy implementation.

> The fix is for the linux kernel to link in libgcc or to use -nostdlib and
> provide its own memcpy routine.

I can't see how linking libgcc helps; it does not provide a version of
memcpy, either. GCC currently assumes that the programs it generates
will be linked with the system's standard C library; that assumption
is incorrect for a freestanding environment. According to C99, section
4, paragraph 6, in a freestanding environment, only the following
headers are available:

<float.h> 
<iso646.h> 
<limits.h> 
<stdarg.h>
<stdbool.h>
<stddef.h>
<stdint.h>

As you can see, <string.h> is not required for a free-standing
environment, so the kernel is absolutely right not to provide one.

If it is a GCC requirement that <string.h> must be provided even in a
freestanding environment, then this requirement should be documented
(e.g. as an implementation restriction).

Regards,
Martin

Re: Patch to allow strlen expander to fail

[Jeffrey A Law]

  In message < 200003070310.TAA24843@racerx.synopsys.com >you write:
  > > Any code which depends on gcc generating or not generating libcalls is
  > > broken.
  > 
  > Let a and b be of type "struct foo".
  > 
  > Then it would appear that the statement
  > 
  > 	a = b;
  > 
  > is broken.  How should this code be fixed?
Joe, you're missing the point.

The programmer can not and should not need to know the details of how that
assignment is performed.  If they think they need control over that kind of
implementation detail, then they're barking up the wrong tree.

The programmer has said make a copy, how the compiler chooses to do that is
the compiler's decision.

The fix is for the linux kernel to link in libgcc or to use -nostdlib and
provide its own memcpy routine.

jeff

Re: Patch to allow strlen expander to fail

[Joe Buck]

> Any code which depends on gcc generating or not generating libcalls is
> broken.

Let a and b be of type "struct foo".

Then it would appear that the statement

	a = b;

is broken.  How should this code be fixed?

>   > There was recently a problem with the Linux kernel because gcc
>   > willy-nilly called memcpy(3), and that one isn't around in the kernel,
> Then that's a kernel problem.  They're depending on a specific, undocumented
> and highly implementation dependent behavior in the compiler.  That's dumb.

Again, what's the fix?  Should the Linux kernel's inline memory copy
routine be named memcpy?

Re: Patch to allow strlen expander to fail

[Horst von Brand]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Jeffrey A Law <law@cygnus.com> said:

[...]

>   > Is there some documentation about the functions gcc might generate calls
>   > to? 

> No, and any such documentation would have the caveat that the conditions
> under which GCC will use a libcall can change without warning or
> predictability.

That is OK with me.

> Any code which depends on gcc generating or not generating libcalls is
> broken.

That is exactly what I'm trying to say: If you want to use gcc as a
freestanding C implementation, you'll have to provide those "libc" functions
gcc might generate calls to. Advance notice of the possibility is in order
IMHO.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile                               +56 32 672616

Re: Patch to allow strlen expander to fail

[Jamie Lokier]

Jeffrey A Law wrote:
>   > There was recently a problem with the Linux kernel because gcc
>   > willy-nilly called memcpy(3), and that one isn't around in the kernel,
> Then that's a kernel problem.  They're depending on a specific, undocumented
> and highly implementation dependent behavior in the compiler.  That's dumb.

The problem is that GCC emits out of line calls to memcpy for structure
copies.  Linux provides a perfectly good inline memcpy function, but it
is not used by GCC.

To work around this, people are supposed to use a "struct_cpy" macro
instead of structure assignment.  Ugly, easily forgotten, and not
required for all architectures.  But it works.

-- Jamie

Re: Patch to allow strlen expander to fail

[Jeffrey A Law]

  In message < 200003060159.e261xPj06505@sleipnir.valparaiso.cl >you write:
  > Jan Hubicka <hubicka@atrey.karlin.mff.cuni.cz> said on gcc-patches:
  > > This patch adds the strlen libcall and necesary code to emit_builtin_strl
  > en
  > > to emit libcall when strlen expander fails.
  > 
  > Is there some documentation about the functions gcc might generate calls
  > to? 
No, and any such documentation would have the caveat that the conditions
under which GCC will use a libcall can change without warning or
predictability.

Any code which depends on gcc generating or not generating libcalls is
broken.

  > There was recently a problem with the Linux kernel because gcc
  > willy-nilly called memcpy(3), and that one isn't around in the kernel,
Then that's a kernel problem.  They're depending on a specific, undocumented
and highly implementation dependent behavior in the compiler.  That's dumb.

jeff

Re: Patch to allow strlen expander to fail

[Horst von Brand]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

Jan Hubicka <hubicka@atrey.karlin.mff.cuni.cz> said on gcc-patches:
> This patch adds the strlen libcall and necesary code to emit_builtin_strlen
> to emit libcall when strlen expander fails.

Is there some documentation about the functions gcc might generate calls
to? There was recently a problem with the Linux kernel because gcc
willy-nilly called memcpy(3), and that one isn't around in the kernel,
which relies either on reimplementations (through a mass of macros, which
end up calling something called differently) or on ths gcc builtins. At
least, there should be a mini-library (or a list at the very least) of the
non-libgcc functions that the compiler could generate calls to.

I assume this would be needed for a freestanding C implementation, at least?
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile                               +56 32 672616