This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: mips static constructor changes



  In message <Pine.LNX.4.10.9904161123530.4516-100000@oar3remote>you write:
  > > EXTRA_MULTILIB_PARTS = crtbegin.o crtend.o
  > > # Don't let CTOR_LIST end up in sdata section.
  > > CRTSTUFF_T_CFLAGS = -G 0
  > 
  > I looked at the various rtems targets and most of their cousins don't
  > reference crtbegin/crtend.  Is there something I have to do in the
  > gcc/XXX/rtems.h files in addition.
Possibly.  Depends on what other files they include.  If you look at the
ChangeLog for that change you'll see a series of changes to mips/elf.h.  
You may need to mirror one or more of those changes if the appropriate
defines are not provided by some file you're including in rtems.h.



  > Just to make me feel comfortable for m68k-rtems (based on m68k-coff) is
  > all I have to do is add the extra_parts = "crtbegin.o crtend.o" line
  > in the right spot in configure.in?  (or config/m68k/t-rtems)? 
  > 
  > FYI I will try to stick to adding it in configure.in since although there
  > is a config/t-rtems, there are not any config/XXX/t-rtems files. If I take
  > the config/XXX/t-rtems approach, I will likely be forced to add a lot of
  > files.  Would adding it to config/t-rtems be the better approach?  What
  > about targets like powerpc-rtems which use crt[in].o?
t-rtems might be the best approach since I think you do need these files
multilib those files.

I have no idea how crt[in].o are used.  You'll have to experiment a little with
them.

  > And on another subject, is it preferable to pull in crtbegin/end via specs
  > or linker scripts?
Unknown.  I think Cygnus usually does it via linker scripts.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]