* Re: cvs binutils+gcc4.0 build fail
[not found] ` <20050322222308.GE30711@bubble.modra.org>
@ 2005-03-29 13:54 ` Alan Modra
2005-03-29 15:43 ` Alan Modra
0 siblings, 1 reply; 4+ messages in thread
From: Alan Modra @ 2005-03-29 13:54 UTC (permalink / raw)
To: Ben Elliston; +Cc: Anton Blanchard, binutils
On Wed, Mar 23, 2005 at 08:53:08AM +1030, Alan Modra wrote:
> On Wed, Mar 23, 2005 at 08:32:19AM +1100, Ben Elliston wrote:
> > > Does this look familiar?
> >
> > Not immediately.
> >
> > > /usr/local/ppc64-4.0/bin/powerpc-linux-ld:
> > > .libs/wstring-inst.o(.eh_frame+0x13c8): R_PPC64_REL64 reloc against
> > > `.gnu.linkonce.t._ZNKSbIwSt11char_traitsIwESaIwEE7compareEmmRKS2_mm':
> > > error 2
> >
> > So _bfd_final_link_relocate is returning bfd_reloc_outofrange. I
> > suspect the remaining errors just cascade from that. As to why this
> > is happening, I don't know. Alan?
>
> My guess is that the .gnu.linkonce.* section in question has been
> removed because it's a duplicate, and something has gone wrong with
> .eh_frame editing. We have had a lot of problems with linkonce
> sections in the past, but I thought it was all OK now..
Something was indeed going wrong with eh_frame editing. It was being
done twice due to my 2005-03-21 ppc64elf.em change. Oops.
* emultempl/ppc64elf.em (need_laying_out): Delete. Remove all refs.
(ppc_finish): Don't call bfd_elf_discard_info.
* emultempl/hppaelf.em: Similarly.
Index: ld/emultempl/ppc64elf.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/ppc64elf.em,v
retrieving revision 1.40
diff -u -p -r1.40 ppc64elf.em
--- ld/emultempl/ppc64elf.em 21 Mar 2005 09:39:53 -0000 1.40
+++ ld/emultempl/ppc64elf.em 29 Mar 2005 06:37:13 -0000
@@ -32,9 +32,6 @@ cat >>e${EMULATION_NAME}.c <<EOF
static lang_input_statement_type *stub_file;
static int stub_added = 0;
-/* Whether we need to call ppc_layout_sections_again. */
-static int need_laying_out = 0;
-
/* Maximum size of a group of input sections that can be handled by
one stub section. A value of +/-1 indicates the bfd back-end
should use a suitable default size. */
@@ -258,8 +255,6 @@ ppc_layout_sections_again (void)
/* If we have changed sizes of the stub sections, then we need
to recalculate all the section offsets. This may mean we need to
add even more stubs. */
- need_laying_out = 0;
-
lang_reset_memory_regions ();
/* Resize the sections. */
@@ -321,13 +316,6 @@ ppc_finish (void)
descriptor in the .opd section. */
entry_section = ".opd";
- /* bfd_elf_discard_info just plays with debugging sections,
- ie. doesn't affect any code, so we can delay resizing the
- sections. It's likely we'll resize everything in the process of
- adding stubs. */
- if (bfd_elf_discard_info (output_bfd, &link_info))
- need_laying_out = 1;
-
/* If generating a relocatable output file, then we don't have any
stubs. */
if (stub_file != NULL && !link_info.relocatable)
@@ -356,9 +344,6 @@ ppc_finish (void)
}
}
- if (need_laying_out)
- ppc_layout_sections_again ();
-
if (link_info.relocatable)
{
asection *toc = bfd_get_section_by_name (output_bfd, ".toc");
Index: ld/emultempl/hppaelf.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/hppaelf.em,v
retrieving revision 1.38
diff -u -p -r1.38 hppaelf.em
--- ld/emultempl/hppaelf.em 21 Mar 2005 09:39:53 -0000 1.38
+++ ld/emultempl/hppaelf.em 29 Mar 2005 06:37:13 -0000
@@ -36,9 +36,6 @@ static lang_input_statement_type *stub_f
stubs. */
static int multi_subspace = 0;
-/* Whether we need to call hppa_layout_sections_again. */
-static int need_laying_out = 0;
-
/* Maximum size of a group of input sections that can be handled by
one stub section. A value of +/-1 indicates the bfd back-end
should use a suitable default size. */
@@ -220,8 +217,6 @@ hppaelf_layout_sections_again (void)
/* If we have changed sizes of the stub sections, then we need
to recalculate all the section offsets. This may mean we need to
add even more stubs. */
- need_laying_out = 0;
-
lang_reset_memory_regions ();
/* Resize the sections. */
@@ -258,13 +253,6 @@ build_section_lists (lang_statement_unio
static void
hppaelf_finish (void)
{
- /* bfd_elf_discard_info just plays with debugging sections,
- ie. doesn't affect any code, so we can delay resizing the
- sections. It's likely we'll resize everything in the process of
- adding stubs. */
- if (bfd_elf_discard_info (output_bfd, &link_info))
- need_laying_out = 1;
-
/* If generating a relocatable output file, then we don't
have to examine the relocs. */
if (stub_file != NULL && !link_info.relocatable)
@@ -296,9 +284,6 @@ hppaelf_finish (void)
}
}
- if (need_laying_out)
- hppaelf_layout_sections_again ();
-
if (! link_info.relocatable)
{
/* Set the global data pointer. */
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cvs binutils+gcc4.0 build fail
2005-03-29 13:54 ` cvs binutils+gcc4.0 build fail Alan Modra
@ 2005-03-29 15:43 ` Alan Modra
2005-03-29 23:33 ` Thorsten Glaser
0 siblings, 1 reply; 4+ messages in thread
From: Alan Modra @ 2005-03-29 15:43 UTC (permalink / raw)
To: Ben Elliston, Anton Blanchard, binutils
On Tue, Mar 29, 2005 at 04:21:39PM +0930, Alan Modra wrote:
> Something was indeed going wrong with eh_frame editing. It was being
> done twice due to my 2005-03-21 ppc64elf.em change. Oops.
Blah, it's worse than that. .eh_frame needs to be edited before stubs
and suchlike are built. If the section layout changes after we're done
adding stubs, then some of the stubs will have incorrect offsets.
* emultempl/elf32.em (gld${EMULATION_NAME}_layout_sections_again):
New function, extracted from static void gld${EMULATION_NAME}_finish.
(gld${EMULATION_NAME}_strip_empty_sections): Likewise.
(gld${EMULATION_NAME}_provide_init_fini_syms): Likewise.
* emultempl/ppc64elf.em: Revert last change.
(ppc_layout_sections_again): Use
gld${EMULATION_NAME}_layout_sections_again.
(ppc_finish): Don't call gld${EMULATION_NAME}_finish. Instead call
gld${EMULATION_NAME}_strip_empty_sections and
gld${EMULATION_NAME}_provide_init_fini_syms.
* emultempl/hppaelf.em: Similarly.
Index: ld/emultempl/elf32.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/elf32.em,v
retrieving revision 1.136
diff -c -p -r1.136 elf32.em
*** ld/emultempl/elf32.em 23 Mar 2005 15:35:50 -0000 1.136
--- ld/emultempl/elf32.em 29 Mar 2005 10:53:24 -0000
*************** static void gld${EMULATION_NAME}_after_o
*** 59,65 ****
static void gld${EMULATION_NAME}_before_allocation (void);
static bfd_boolean gld${EMULATION_NAME}_place_orphan
(lang_input_statement_type *file, asection *s);
! static void gld${EMULATION_NAME}_finish (void);
EOF
--- 59,68 ----
static void gld${EMULATION_NAME}_before_allocation (void);
static bfd_boolean gld${EMULATION_NAME}_place_orphan
(lang_input_statement_type *file, asection *s);
! static void gld${EMULATION_NAME}_layout_sections_again (void);
! static void gld${EMULATION_NAME}_strip_empty_sections (void);
! static void gld${EMULATION_NAME}_provide_init_fini_syms (void);
! static void gld${EMULATION_NAME}_finish (void) ATTRIBUTE_UNUSED;
EOF
*************** gld${EMULATION_NAME}_provide_bound_symbo
*** 1450,1474 ****
_bfd_elf_provide_symbol (&link_info, end, end_val);
}
static void
! gld${EMULATION_NAME}_finish (void)
{
! if (bfd_elf_discard_info (output_bfd, &link_info))
{
! lang_reset_memory_regions ();
!
! /* Resize the sections. */
! lang_size_sections (stat_ptr->head, abs_output_section,
! &stat_ptr->head, 0, (bfd_vma) 0, NULL, TRUE);
!
! /* Redo special stuff. */
! ldemul_after_allocation ();
!
! /* Do the assignments again. */
! lang_do_assignments (stat_ptr->head, abs_output_section,
! (fill_type *) 0, (bfd_vma) 0);
}
if (!link_info.relocatable)
{
lang_output_section_statement_type *os;
--- 1453,1510 ----
_bfd_elf_provide_symbol (&link_info, end, end_val);
}
+ /* If not building a shared library, provide
+
+ __preinit_array_start
+ __preinit_array_end
+ __init_array_start
+ __init_array_end
+ __fini_array_start
+ __fini_array_end
+
+ They are set here rather than via PROVIDE in the linker
+ script, because using PROVIDE inside an output section
+ statement results in unnecessary output sections. Using
+ PROVIDE outside an output section statement runs the risk of
+ section alignment affecting where the section starts. */
+
static void
! gld${EMULATION_NAME}_provide_init_fini_syms (void)
{
! if (!link_info.relocatable && !link_info.shared)
{
! gld${EMULATION_NAME}_provide_bound_symbols (".preinit_array",
! "__preinit_array_start",
! "__preinit_array_end");
! gld${EMULATION_NAME}_provide_bound_symbols (".init_array",
! "__init_array_start",
! "__init_array_end");
! gld${EMULATION_NAME}_provide_bound_symbols (".fini_array",
! "__fini_array_start",
! "__fini_array_end");
}
+ }
+ static void
+ gld${EMULATION_NAME}_layout_sections_again (void)
+ {
+ lang_reset_memory_regions ();
+
+ /* Resize the sections. */
+ lang_size_sections (stat_ptr->head, abs_output_section,
+ &stat_ptr->head, 0, (bfd_vma) 0, NULL, TRUE);
+
+ /* Redo special stuff. */
+ ldemul_after_allocation ();
+
+ /* Do the assignments again. */
+ lang_do_assignments (stat_ptr->head, abs_output_section,
+ (fill_type *) 0, (bfd_vma) 0);
+ }
+
+ static void
+ gld${EMULATION_NAME}_strip_empty_sections (void)
+ {
if (!link_info.relocatable)
{
lang_output_section_statement_type *os;
*************** gld${EMULATION_NAME}_finish (void)
*** 1495,1529 ****
}
}
}
! /* If not building shared library, provide
! __preinit_array_start
! __preinit_array_end
! __init_array_start
! __init_array_end
! __fini_array_start
! __fini_array_end
!
! They are set here rather than via PROVIDE in the linker
! script, because using PROVIDE inside an output section
! statement results in unnecessary output sections. Using
! PROVIDE outside an output section statement runs the risk of
! section alignment affecting where the section starts. */
!
! if (!link_info.shared)
! {
! gld${EMULATION_NAME}_provide_bound_symbols
! (".preinit_array", "__preinit_array_start",
! "__preinit_array_end");
! gld${EMULATION_NAME}_provide_bound_symbols
! (".init_array", "__init_array_start",
! "__init_array_end");
! gld${EMULATION_NAME}_provide_bound_symbols
! (".fini_array", "__fini_array_start",
! "__fini_array_end");
! }
! }
}
EOF
fi
--- 1531,1547 ----
}
}
}
+ }
+ }
! static void
! gld${EMULATION_NAME}_finish (void)
! {
! if (bfd_elf_discard_info (output_bfd, &link_info))
! gld${EMULATION_NAME}_layout_sections_again ();
! gld${EMULATION_NAME}_strip_empty_sections ();
! gld${EMULATION_NAME}_provide_init_fini_syms ();
}
EOF
fi
Index: ld/emultempl/ppc64elf.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/ppc64elf.em,v
retrieving revision 1.41
diff -u -p -r1.41 ppc64elf.em
--- ld/emultempl/ppc64elf.em 29 Mar 2005 06:52:22 -0000 1.41
+++ ld/emultempl/ppc64elf.em 29 Mar 2005 10:33:56 -0000
@@ -32,6 +32,9 @@ cat >>e${EMULATION_NAME}.c <<EOF
static lang_input_statement_type *stub_file;
static int stub_added = 0;
+/* Whether we need to call ppc_layout_sections_again. */
+static int need_laying_out = 0;
+
/* Maximum size of a group of input sections that can be handled by
one stub section. A value of +/-1 indicates the bfd back-end
should use a suitable default size. */
@@ -255,17 +258,9 @@ ppc_layout_sections_again (void)
/* If we have changed sizes of the stub sections, then we need
to recalculate all the section offsets. This may mean we need to
add even more stubs. */
- lang_reset_memory_regions ();
-
- /* Resize the sections. */
- lang_size_sections (stat_ptr->head, abs_output_section,
- &stat_ptr->head, 0, 0, NULL, TRUE);
-
- /* Recalculate TOC base. */
- ldemul_after_allocation ();
+ need_laying_out = 0;
- /* Do the assignments again. */
- lang_do_assignments (stat_ptr->head, abs_output_section, NULL, 0);
+ gld${EMULATION_NAME}_layout_sections_again ();
}
@@ -316,6 +311,13 @@ ppc_finish (void)
descriptor in the .opd section. */
entry_section = ".opd";
+ /* bfd_elf_discard_info just plays with debugging sections,
+ ie. doesn't affect any code, so we can delay resizing the
+ sections. It's likely we'll resize everything in the process of
+ adding stubs. */
+ if (bfd_elf_discard_info (output_bfd, &link_info))
+ need_laying_out = 1;
+
/* If generating a relocatable output file, then we don't have any
stubs. */
if (stub_file != NULL && !link_info.relocatable)
@@ -344,6 +346,9 @@ ppc_finish (void)
}
}
+ if (need_laying_out)
+ ppc_layout_sections_again ();
+
if (link_info.relocatable)
{
asection *toc = bfd_get_section_by_name (output_bfd, ".toc");
@@ -374,7 +379,8 @@ ppc_finish (void)
}
ppc64_elf_restore_symbols (&link_info);
- gld${EMULATION_NAME}_finish ();
+ gld${EMULATION_NAME}_strip_empty_sections ();
+ gld${EMULATION_NAME}_provide_init_fini_syms ();
}
Index: ld/emultempl/hppaelf.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/hppaelf.em,v
retrieving revision 1.39
diff -u -p -r1.39 hppaelf.em
--- ld/emultempl/hppaelf.em 29 Mar 2005 06:52:22 -0000 1.39
+++ ld/emultempl/hppaelf.em 29 Mar 2005 10:33:56 -0000
@@ -36,6 +35,9 @@ static lang_input_statement_type *stub_f
stubs. */
static int multi_subspace = 0;
+/* Whether we need to call hppa_layout_sections_again. */
+static int need_laying_out = 0;
+
/* Maximum size of a group of input sections that can be handled by
one stub section. A value of +/-1 indicates the bfd back-end
should use a suitable default size. */
@@ -217,18 +219,9 @@ hppaelf_layout_sections_again (void)
/* If we have changed sizes of the stub sections, then we need
to recalculate all the section offsets. This may mean we need to
add even more stubs. */
- lang_reset_memory_regions ();
+ need_laying_out = 0;
- /* Resize the sections. */
- lang_size_sections (stat_ptr->head, abs_output_section,
- &stat_ptr->head, 0, (bfd_vma) 0, NULL, TRUE);
-
- /* Redo special stuff. */
- ldemul_after_allocation ();
-
- /* Do the assignments again. */
- lang_do_assignments (stat_ptr->head, abs_output_section,
- (fill_type *) 0, (bfd_vma) 0);
+ gld${EMULATION_NAME}_layout_sections_again ();
}
@@ -253,6 +246,13 @@ build_section_lists (lang_statement_unio
static void
hppaelf_finish (void)
{
+ /* bfd_elf_discard_info just plays with debugging sections,
+ ie. doesn't affect any code, so we can delay resizing the
+ sections. It's likely we'll resize everything in the process of
+ adding stubs. */
+ if (bfd_elf_discard_info (output_bfd, &link_info))
+ need_laying_out = 1;
+
/* If generating a relocatable output file, then we don't
have to examine the relocs. */
if (stub_file != NULL && !link_info.relocatable)
@@ -284,6 +284,9 @@ hppaelf_finish (void)
}
}
+ if (need_laying_out)
+ hppaelf_layout_sections_again ();
+
if (! link_info.relocatable)
{
/* Set the global data pointer. */
@@ -297,14 +300,12 @@ hppaelf_finish (void)
if (stub_file != NULL && stub_file->the_bfd->sections != NULL)
{
if (! elf32_hppa_build_stubs (&link_info))
- {
- einfo ("%X%P: can not build stubs: %E\n");
- return;
- }
+ einfo ("%X%P: can not build stubs: %E\n");
}
}
- gld${EMULATION_NAME}_finish ();
+ gld${EMULATION_NAME}_strip_empty_sections ();
+ gld${EMULATION_NAME}_provide_init_fini_syms ();
}
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cvs binutils+gcc4.0 build fail
2005-03-29 15:43 ` Alan Modra
@ 2005-03-29 23:33 ` Thorsten Glaser
2005-03-30 16:34 ` Alan Modra
0 siblings, 1 reply; 4+ messages in thread
From: Thorsten Glaser @ 2005-03-29 23:33 UTC (permalink / raw)
To: binutils
Alan Modra dixit:
>On Tue, Mar 29, 2005 at 04:21:39PM +0930, Alan Modra wrote:
>> Something was indeed going wrong with eh_frame editing. It was being
>> done twice due to my 2005-03-21 ppc64elf.em change. Oops.
>
>Blah, it's worse than that. .eh_frame needs to be edited before stubs
>and suchlike are built. If the section layout changes after we're done
>adding stubs, then some of the stubs will have incorrect offsets.
I've got a similar problem; just applying your emultempl/elf32.em diff
on top of a binutils-20050328 snapshot didn't help :-(
This is gcc-3.4.4 (20050325).
tg@odem:/home/tg $ g++ -static x.cc
/usr/bin/ld: `.gnu.linkonce.t._ZNKSt5ctypeIcE13_M_widen_initEv' referenced in section `.data' of /usr/lib/libstdc++.a(locale-inst.o): defined in discarded section `.gnu.linkonce.t._ZNKSt5ctypeIcE13_M_widen_initEv' of /usr/lib/libstdc++.a(locale-inst.o)
/usr/bin/ld: `.gnu.linkonce.t._ZStneIcSt11char_traitsIcESaIcEEbRKSbIT_T0_T1_EPKS3_' referenced in section `.data' of /usr/lib/libstdc++.a(locale_init.o): defined in discarded section `.gnu.linkonce.t._ZStneIcSt11char_traitsIcESaIcEEbRKSbIT_T0_T1_EPKS3_' of /usr/lib/libstdc++.a(locale_init.o)
tg@odem:/home/tg $ ./a.out
Segmentation fault (core dumped)
tg@odem:/home/tg $ cat x.cc
#include <iostream>
using namespace std;
main() { cout << "Hello, World!" << endl; }
tg@odem:/home/tg $ uname -a
MirBSD odem.66h.42h.de 8 Kv#8n24-20050315 GENERIC#660 i386
Do you have an idea if this is a binutils or a gcc problem?
Thanks in advance,
//mirabile, who doesn't know C++ but got the task to port it to MirOS
PS: Yes, this target isn't supported (yet) in stock binutils,
but I've got my papers done, just got no time to split our
diff up into smaller pieces and feed back.
--
> [...] Echtzeit hat weniger mit "Speed"[...] zu tun, sondern damit, daß der
> richtige Prozeß voraussagbar rechtzeitig sein Zeitscheibchen bekommt.
Wir haben uns[...] geeinigt, dass das verwendete Echtzeit-Betriebssystem[...]
weil selbst einfachste Operationen *echt* *Zeit* brauchen. (aus d.a.s.r)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: cvs binutils+gcc4.0 build fail
2005-03-29 23:33 ` Thorsten Glaser
@ 2005-03-30 16:34 ` Alan Modra
0 siblings, 0 replies; 4+ messages in thread
From: Alan Modra @ 2005-03-30 16:34 UTC (permalink / raw)
To: Thorsten Glaser; +Cc: binutils
On Tue, Mar 29, 2005 at 07:09:31PM +0000, Thorsten Glaser wrote:
> tg@odem:/home/tg $ g++ -static x.cc
> /usr/bin/ld: `.gnu.linkonce.t._ZNKSt5ctypeIcE13_M_widen_initEv' referenced in section `.data' of /usr/lib/libstdc++.a(locale-inst.o): defined in discarded section `.gnu.linkonce.t._ZNKSt5ctypeIcE13_M_widen_initEv' of /usr/lib/libstdc++.a(locale-inst.o)
This is a gcc problem. Some part of _ZNKSt5ctypeIcE13_M_widen_initEv is
not being emitted to linkonce sections, but instead finds its way into
.data. This leaves a dangling reference when the linkonce sections are
removed due to some other copy of _ZNKSt5ctypeIcE13_M_widen_initEv
already being present.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-03-29 22:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20050322212341.GD4980@krispykreme>
[not found] ` <20050323083219.A21240@mailhub.air.net.au>
[not found] ` <20050322222308.GE30711@bubble.modra.org>
2005-03-29 13:54 ` cvs binutils+gcc4.0 build fail Alan Modra
2005-03-29 15:43 ` Alan Modra
2005-03-29 23:33 ` Thorsten Glaser
2005-03-30 16:34 ` Alan Modra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).