This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Your change to ldlang.c
From: Mark Mitchell <mark@codesourcery.com>
Date: Thu, 01 Jul 1999 20:30:04 -0700
Ian> My main concern was that it would mess up relocations. If an
Ian> input section disappears, relocations against symbols in that
Ian> section need to be adjusted to use different symbols, and
Ian> relocations for that section need to disappear. I doubt the
Ian> backends do either of these correctly.
I see. Of course, in this case, there are no relocations against the
section.
I guess I don't see why your solution is really any better. On the
one hand, we may have bogus relocations. On the other, we've violated
the SEC_LINK_ONCE semantics, especially for fixed-sized sections like
.reginfo.
It's not clear to me what SEC_LINK_ONCE semantics are in the case of a
relocateable link. My first reaction when I noticed this was actually
that a relocateable link should keep all the sections, and that the
current behaviour was simply a bug.
SEC_LINK_ONCE was originally meant to be something along the lines of
PE COMDAT sections. Can anybody check what the Microsoft linker does
when doing a relocateable link with multiple COMDAT sections?
I guess I'm thinking we should undo your change, and then attack the
problem of making the back-ends handle the relocations correctly.
That should not be *that* hard.
It's not trivial, actually, when you consider relocations against
local symbols in a linkonce section. In some cases those relocations
can simply be removed, as in a debugging section, but in other cases
you need to actually modify the relocation to a different section. I
think every backend would have to be modified.
Ian> We could go back to letting the emultempl file handle the
Ian> .reginfo sections for MIPS files when doing a relocateable
Ian> link, I suppose. Does anybody have a better suggestion?
I don't know what you mean by this suggestion. I guess I'm too new to
binutils-land. Could you elaborate on the emultempl file solution?
Until quite recently (February 1999), .reginfo sections were not
marked as LINK_ONCE, and they were instead handled in the emultempl
file. The special handling was removed by this patch:
Wed Feb 17 12:10:06 1999 Stan Cox <scox@cygnus.com>
* mpw-elfmips.c (gldelf32ebmip_before_allocation): Remove special
.reginfo section handling.
* emultempl/elf32.em (gld${EMULATION_NAME}_before_allocation): Likewise.
* emulparams/elf32elmip.sh (INITIAL_READONLY_SECTIONS): Removed
* emulparams/elf32ebmip.sh (INITIAL_READONLY_SECTIONS): Removed
Index: elf32.em
===================================================================
RCS file: /cvs/cvsfiles/devo/ld/emultempl/elf32.em,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- elf32.em 1998/09/20 04:16:36 1.57
+++ elf32.em 1999/02/17 19:58:05 1.58
@@ -762,37 +762,6 @@
s->_raw_size = 0;
}
}
-
-#if defined (TARGET_IS_elf32bmip) || defined (TARGET_IS_elf32lmip)
- /* For MIPS ELF the .reginfo section requires special handling.
- Each input section is 24 bytes, and the final output section must
- also be 24 bytes. We handle this by clobbering all but the first
- input section size to 0. The .reginfo section is handled
- specially by the backend code anyhow. */
- {
- boolean found = false;
- LANG_FOR_EACH_INPUT_STATEMENT (is)
- {
- asection *s;
-
- if (is->just_syms_flag)
- continue;
-
- s = bfd_get_section_by_name (is->the_bfd, ".reginfo");
- if (s == NULL)
- continue;
-
- if (! found)
- {
- found = true;
- continue;
- }
-
- s->_raw_size = 0;
- s->_cooked_size = 0;
- }
- }
-#endif
}
/* This is called by the before_allocation routine via