This is the mail archive of the 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: [PATCH] Handle weak symbols

Franz --

  Thanks for the patch.

  My reply is in two parts:

  - Things that need to be done to improve the patch.

  - Questions that I need to know the answers to in order to 
    understand whether or not this change needs to go on the branch.

  Here are the improvements:

  - is_on_pending_weak_list:

    - Needs documentation

    - Should return `bool'.

    - Should use a splay-tree or hash-table to do the lookups.
      Note that this means reworking other routines that handle
      weak_decls as well.

      make_decl_rtl is called a ton and in C++ especially there
      are a ton of weak symbols, so your change would introduce
      new quadratic behavior.

  - We should be using `if' rather than `#ifdef' according to 
    our new coding standards.  That means that defaults.h should

      #ifndef HANDLE_PRAGMA_WEAK
      #define HANDLE_PRAGMA_WEAK 0
    and then we should use #if instead of #ifdef throughout the

  - The way declare_weak works isn't very good because it forces
    the computation of DECL_ASSEMBLER_NAME.  We shouldn't 
    need to do that until the last possible minute, probably 
    in weak_finish.  And there we should only call ASM_WEAKEN_LABEL
    for decls that have DECL_ASSEMBLER_NAME_SET_P and

    In general, it's bogus to do things based on assembler names, 
    not just because of the laziness there, but also because
    programmers don't talk about *names* they talk about *entities*.

    So, we should change this too.

  - I don't understand why we need to disable the check in
    declare_weak.  That seems like a good check.

  Uh-oh.  I realize that I've now asked you to go way beyond fixing a
bug, and all the way to reimplementing this gunk.  That's not really
fair, but I still don't want to introduce the new quadratic behavior.

  Now, the other questions:

  - Why do we need this on the branch?

  - In particular, does GCC 3.0 handle some testcase worse than
    GCC 2.95.2?  If so, do you have a little test-case to show?

  - Or, are development versions of glibc using some new construct
    that old ones didn't?  If so, why?

  Assume I am an idiot and explain it all in gory detail.  I'm not the
world's best expert on linker semantics, etc.

  Thank you,

Mark Mitchell         
CodeSourcery, LLC     

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