The attached patches correct an issue that exists in ld when the object
code format is TI COFF.
The problem is that struct external_scnhdr in ti.h define two members,
s_reserved and s_page, which are not always set before the section header
is written to the output. The output file in TI COFF works nicely except
that subsequent ld invocations may produce files which are not identical.
I have for instance seen the length of the output file name affect the
resulting values of s_reserved and s_page.
Please consider these patches for future binutils releases.
I found the problem in an older version of binutils but have verified that
these members remain unset in the CVS head revisions. The patches are
relative to the CVS head revisions as of today, coffcode.h rev. 1.144 and
ti.h rev. 1.18.
Thanks,
Johan Olmutz Nielsen
--- coffcode.h.1.144 2008-12-06 12:45:12.393963200 +0100
+++ coffcode.h 2008-12-06 12:57:45.576987200 +0100
@@ -3528,6 +3528,8 @@
section.s_size = current->size;
#ifdef coff_get_section_load_page
section.s_page = coff_get_section_load_page (current);
+#else
+ section.s_page = 0;
#endif
#ifdef COFF_WITH_PE
--- ti.h.1.18 2008-12-06 12:51:52.609444800 +0100
+++ ti.h 2008-12-06 12:56:26.503284800 +0100
@@ -321,6 +321,16 @@
} \
while (0)
+/* The entire scnhdr may not be assigned.
+ Ensure that everything is initialized.
+ */
+#define COFF_ADJUST_SCNHDR_OUT_PRE(ABFD, INT, EXT) \
+ do \
+ { \
+ memset((EXT), 0, sizeof(SCNHDR)); \
+ } \
+ while (0)
+
/* The line number and reloc overflow checking in coff_swap_scnhdr_out in
coffswap.h doesn't use PUT_X for s_nlnno and s_nreloc.
Due to different sized v0/v1/v2 section headers, we have to re-write
these
This message is intended only for the use of the individual or entity to which
it is addressed. If the reader of this message is not the intended recipient,
or the employee or agent responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this message is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to the sender
of this E-Mail by return E-Mail or by telephone.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
