Re: [3.3 regression?] flag_hosted and back-ends

[cgd at broadcom dot com]

At Sat, 15 Mar 2003 00:22:45 +0000 (UTC), "Jason R Thorpe" wrote:
> On Fri, Mar 14, 2003 at 03:54:18PM -0800, Geoff Keating wrote:
>  > Why can't GRUB supply its own __enable_execute_stack function, that
>  > does whatever the right thing is for GRUB's environment?
> 
> I can see a couple of reasons why that would not be appropriate:
> 
> 	* Random applications should not have to know about internal
> 	  routines in libgcc.

however, random applications, if freestanding, may have provide
certain functions that would otherwise be implemented by the hosted
environment, if they want to use all of GCC's features.

(Another example of that is the cacheflush stuff on MIPS.)


> 	* An application that uses -ffreestanding has pretty much
> 	  told the compiler "don't assume I'm in a hosted environment".
> 	  The __enable_execute_stack() function *does* assume a hosted
> 	  environment.  It seems perfectly logical that it should not
> 	  be used if the application is free-standing.

In general, then, is it safe to assume that in a freestanding
environment that the stack will always be executable?

I don't see why that's a safe assumption.  In which case, you do need
to call _some_ function, eh?


In some sense, you could say that a lack of a working
__enable_execute_stack (on platforms that may need it) in a
freestanding environment means that that freestanding environment
doesn't support things that need it.  (Just like, say, lack of a
working cache flush rtn may mean the same thing, on other platforms.)

Maybe it's a bummer that the name of the routine is hard-wired (e.g.,
the mips cache flush rtn name is settable, iirc).  But that means that
you should provide a mechanism to change the name, not disable it.
Some freestanding environments may need it!


cgd