Re: GCC_DRIVER_HOST_INITIALIZATION in gcc.c

[Jim Wilson <wilson at specifixinc dot com>]

On Tue, 2004-01-20 at 18:22, DJ Delorie wrote:
> Ok, you start off with an invalid assumption.  It *is* modified.

I have no idea what code you are looking at.  I am looking at the code
in gcc.c for standard_startfile_prefix.  It you look at the code, it is
obvious that standard_startfile_prefix is never set other than when it
is initialized to point to a constant string.  This is why it is const.

It is set for the djgpp port in the config/i386/xm-djgpp.h file, but
this is completely hidden from gcc.c.  This is a serious design flaw. 
We can either remove the const thereby perpetuating a design flaw, or we
can discuss ways to fix the design flaw.  Since the design flaw appears
to be easy to fix, I can not in good conscience accept a patch which
perpetuates the design flaw, at least not without a discussion.  I find
your refusal to discuss this very puzzling.  I don't understand why you
are being difficult.

> 	/* This may be changed by the target */
> 	char * startfile_prefix = "something";
> 
> 	scan_directory(startfile_prefix);

I see no such code in mainline gcc or gcc-3.3.  There is no
scan_directory function call.  There is no startfile_prefix variable. 
Your argument makes no sense at all to me.

The actual code is
static const char *const standard_startfile_prefix =
STANDARD_STARTFILE_PREFIX;

#ifdef GCC_DRIVER_HOST_INITIALIZATION
  /* Perform host dependent initialization when needed.  */
  GCC_DRIVER_HOST_INITIALIZATION;
#endif

The second const has to be removed to make djgpp work.  It is impossible
for someone looking at gcc.c to understand why, because there is no way
to know that the GCC_DRIVER_HOST_INITIALIZATION macro might set it. 
This is a problem that needs to be fixed.

Here is yet another suggestion on how to fix the problem.  Replace the
above code with
static const char * standard_startfile_prefix;

#ifndef UPDATE_PATH_HOST_CANONICALIZE
#define UPDATE_PATH_HOST_CANONICALIZE(ARG) ARG
#endif
  standard_startfile_prefix = UPDATE_PATH_HOST_CANONICALIZE
(STANDARD_STARTFILE_PREFIX);

This has a number of advantages.  It makes it obvious that some ports
modify the standard_startfile_prefix variable.  It makes it obvious why
the variable can't be const.  It eliminates the dangerous
GCC_DRIVER_HOST_INITIALIZATION macro.  A macro which takes no arguments
and has no return value and which is allowed to do anything is
dangerous, as there is no way for someone maintaining gcc.c to ensure
that they haven't broken it.  That is the exact problem we have now.  A
perfectly reasonable change broken dgjpp because too much is hidden
inside that macro.

Here is yet another simpler suggestion: delete the code in
GCC_DRIVER_HOST_INITIALIZATION that modifies standard_startfile_prefix. 
I don't see the point of it.  The code in gcc.c will already pass
standard_startfile_prefix through update_path when add_prefix is called,
so I don't see why we need a second update_path call in the
GCC_DRIVER_HOST_INITIALIZATION macro.  If there is a non-obvious reason
why this is needed, then it would be nice to document it in a comment,
and we can use the above suggestion.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com