This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Handle weak symbols
- To: Franz dot Sirl-kernel at lauterbach dot com
- Subject: Re: [PATCH] Handle weak symbols
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Sun, 06 May 2001 14:22:02 -0700
- Cc: gcc-patches at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <email@example.com>
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:
- 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
#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.
Mark Mitchell firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com