Can someone give a more detailed explanation of what -rdynamic
does exactly? As far as I can see in the explanation so far,
it's just a flag passed down to collect2 which is the linker?
Does that require the compiler to behavior different in terms
of code generations, such as "stubs" generation for function calls
etc? How will that different from the ABI as specified by the Intel
documents?
Sun
> -----Original Message-----
> From: mpm@xxxxxxxxxxxxxxxxx [mailto:mpm@xxxxxxxxxxxxxxxxx]
> Sent: Thursday, April 26, 2001 10:31 AM
> To: suneel_jain@xxxxxx; pro64-support@xxxxxxxxxxx; arnold@xxxxxxxxxx;
> Aharon Robbins
> Cc: beebe@xxxxxxxxxxxxx
> Subject: RE: sgicc, __GNUC__, and -rdynamic
>
>
> From: Aharon Robbins <arnold@xxxxxxxxxx>
>
> I stand corrected. That the two compilers share the
> same front-end
> wasn't obvious. Since that is the case, I'll agree that adding
> -rdynamic support is the right way to go.
>
> As Suneel explained, I think we should define __GNUC__.
> It looks like all gcc does with -rdynamic is to pass -export-dynamic
> to collect2. Is that correct? One question is why not just pass
> -export-dynamic instead of -rdynamic? sgicc currently doesn't handle
> either one, but I can add that easily enough. In the meantime you
> could use -Wl,-export-dynamic.
>
> This information then leads one to ask if the IA-64
> back end will
> eventually be merged into the main GCC code base? And in the
> meantime, for IA-64, why not just make sgicc be gcc?
>
> There is a separate ia64 gcc, that uses the gcc back-end.
> GCC (at least the people we talked to), is not interested in using
> our backend. So we have two competing compilers.
>
> Thanks!
>
> Arnold
>
> > From: "JAIN,SUNEEL (HP-Cupertino,ex1)" <suneel_jain@xxxxxx>
> > To: "'Aharon Robbins'" <arnold@xxxxxxxxxx>,
> > "'pro64-support@xxxxxxxxxxx'"
> <pro64-support@xxxxxxxxxxx>
> > Subject: RE: sgicc, __GNUC__, and -rdynamic
> > Date: Thu, 26 Apr 2001 08:51:19 -0700
> >
> > > Nelson understates the case. The -rdynamic flag
> can't be the only part
> > > of GCC that sgicc doesn't support. There are a slew of
> > > language extensions
> > > that GNU code often makes use of --- properly ifdef-ed, of
> > > course --- and
> > > defining __GNUC__ is just shouting a request for trouble.
> > >
> > > Hmmm, I guess I just paraphrased what Nelson said,
> didn't I? Oh well.
> > >:-)
> > >
> > > > Fix (2) is less desirable, since leaving __GNUC__
> defined can have
> > > > other side effects, as noted in the previous
> paragraph. However, it
> > > > still may be useful to add support for -rdynamic,
> possibly under a
> > > > different name, provided __GNUC__ remains undefined.
> > >
> > > The two issues are and should be treated orthogonally.
> > > Undefining __GNUC__
> > > for sgicc should be done in any case, whether or
> not support
> > > for -rdynamic
> > > is added.
> >
> > The sgicc and sgiCC compilers share frontends, preprocessor,
> > assembler, linker, debugger with GNU gcc/g++
> compilers. They support
> > the same language extensions that the GNU compilers
> do. One way to
> > view the SGI compilers is that they provide an alternate
> > backend for the IA64 architecture.
> >
> > Given this, I think it is perfectly reasonable for sgicc to
> > define __GNUC__. It should be plug compatible to gcc and
> > adding support for -rdynamic seems like the right answer.
> >
> > - Suneel Jain
>
> -- Mike Murphy
> -- mpm@xxxxxxx
> -- quote of the day:
> -- "Time is the most valuable coin in your life. You and
> you alone will
> -- determine how that coin will be spent. Be careful that
> you do not let
> -- other people spend it for you." (Carl Sandburg)
>
|