This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Professional support for Vxworks cross-compiler
- To: dje at watson dot ibm dot com
- Subject: Re: Professional support for Vxworks cross-compiler
- From: Mike Stump <mrs at windriver dot com>
- Date: Fri, 7 Jul 2000 15:11:44 -0700 (PDT)
- Cc: gcc at gcc dot gnu dot org
> To: Mike Stump <mrs@windriver.com>
> cc: gcc@gcc.gnu.org
> Date: Fri, 07 Jul 2000 17:36:57 -0400
> From: David Edelsohn <dje@watson.ibm.com>
> I think that the longcall/shortcall patch needs a lot more
> discussion and cleanup before it can go in.
I agree. I didn't mean to suggest otherwise actually.
> Also, what is the whole mark_fn_as_defined_in_this_file()
> machinery doing? Setting SYMBOL_REF_FLAG under more circumstances?
We basically remember if something is actually defined in the
translation unit, and we later make a codegen choice based upon that.
If we don't have information, we guess conservatively. If a sym has
been defined, then we assume that the whole translation unit fits
within 32 MB (and hence all defined syms are short and undefined syms
are long).
We've been shipping a compiler with that patch in it to customers for
the last couple of years, it seems to satisfy an itch they have. I
kinda like the idea of a reloc for it and a fully relaxing linker, as
then people don't need funky command line switches, or attributes,
also, the reloc approach is more accurate.