* C6x: Fix another problem with rela. and rel. sections
@ 2010-09-22 22:04 Bernd Schmidt
2010-09-22 23:18 ` Joseph S. Myers
2010-10-01 13:47 ` Joseph S. Myers
0 siblings, 2 replies; 6+ messages in thread
From: Bernd Schmidt @ 2010-09-22 22:04 UTC (permalink / raw)
To: binutils; +Cc: Joseph S. Myers
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
TI's compiler for C6x produces both rel. and rela. sections. When
compiling the kernel with it, we end up with rela.init.text and
rel.init.text, and when we then try to use GNU ld to link these objects
together using "-r", the linker aborts with
ld: init/mounts.o: relocation size mismatch in init/do_mounts.o section
.text
ld: final link failed: File in wrong format
That's because in the output we've only made one of the two sections. I
looked around in other targets for ways to fix it, and came across a
definition of elf_fake_sections in elf32-m32r.c. Adding such a function
to elf32-tic6x.c seems to fix the problem.
Ok?
Bernd
[-- Attachment #2: fake.diff --]
[-- Type: text/plain, Size: 1747 bytes --]
* elf32-tic6x.c (elf32_tic6x_fake_sections): New function.
(elf_backend_fake_sections): Define.
Index: elf32-tic6x.c
===================================================================
--- elf32-tic6x.c (revision 297792)
+++ elf32-tic6x.c (working copy)
@@ -1347,6 +1392,35 @@ elf32_tic6x_set_use_rela_p (bfd *abfd, b
elf32_tic6x_tdata (abfd)->use_rela_p = use_rela_p;
}
+static bfd_boolean
+elf32_tic6x_fake_sections (bfd *abfd,
+ Elf_Internal_Shdr *hdr ATTRIBUTE_UNUSED,
+ asection *sec)
+{
+ const char *name;
+
+ name = bfd_get_section_name (abfd, sec);
+
+ /* The generic elf_fake_sections will set up REL_HDR using the
+ default kind of relocations. But, we may actually need both
+ kinds of relocations, so we set up the second header here. */
+ if ((sec->flags & SEC_RELOC) != 0)
+ {
+ struct bfd_elf_section_data *esd;
+ bfd_size_type amt = sizeof (Elf_Internal_Shdr);
+
+ esd = elf_section_data (sec);
+ BFD_ASSERT (esd->rel_hdr2 == NULL);
+ esd->rel_hdr2 = bfd_zalloc (abfd, amt);
+ if (!esd->rel_hdr2)
+ return FALSE;
+ _bfd_elf_init_reloc_shdr (abfd, esd->rel_hdr2, sec,
+ !sec->use_rela_p);
+ }
+
+ return TRUE;
+}
+
static bfd_boolean
elf32_tic6x_mkobject (bfd *abfd)
{
@@ -1754,6 +3034,7 @@ elf32_tic6x_merge_private_bfd_data (bfd
#define elf_backend_default_use_rela_p 1
#define elf_backend_may_use_rel_p 1
#define elf_backend_may_use_rela_p 1
+#define elf_backend_fake_sections elf32_tic6x_fake_sections
#define elf_backend_obj_attrs_arg_type elf32_tic6x_obj_attrs_arg_type
#define elf_backend_obj_attrs_section "__TI_build_attributes"
#define elf_backend_obj_attrs_section_type SHT_C6000_ATTRIBUTES
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: C6x: Fix another problem with rela. and rel. sections
2010-09-22 22:04 C6x: Fix another problem with rela. and rel. sections Bernd Schmidt
@ 2010-09-22 23:18 ` Joseph S. Myers
2010-09-23 1:58 ` Bernd Schmidt
2010-10-01 13:47 ` Joseph S. Myers
1 sibling, 1 reply; 6+ messages in thread
From: Joseph S. Myers @ 2010-09-22 23:18 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: binutils
On Thu, 23 Sep 2010, Bernd Schmidt wrote:
> TI's compiler for C6x produces both rel. and rela. sections. When compiling
> the kernel with it, we end up with rela.init.text and rel.init.text, and when
> we then try to use GNU ld to link these objects together using "-r", the
> linker aborts with
>
> ld: init/mounts.o: relocation size mismatch in init/do_mounts.o section .text
> ld: final link failed: File in wrong format
>
> That's because in the output we've only made one of the two sections. I
> looked around in other targets for ways to fix it, and came across a
> definition of elf_fake_sections in elf32-m32r.c. Adding such a function to
> elf32-tic6x.c seems to fix the problem.
>
> Ok?
The variable "name" in the function you add appears to be set but not
used. OK with that variable removed.
Is it possible to test this in the linker testsuite? That is, can the bug
be exercised starting with objects where each object only contains REL or
only contains RELA relocations, or do you need a single input containing
both (which the GNU assembler won't generate)? (Specify -mgenerate-rel in
#source rather than #as in the .d file to have it apply only to some of
the input files.) If it can be tested, a test should be added to
ld-tic6x.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: C6x: Fix another problem with rela. and rel. sections
2010-09-22 23:18 ` Joseph S. Myers
@ 2010-09-23 1:58 ` Bernd Schmidt
2010-09-23 15:36 ` Joseph S. Myers
0 siblings, 1 reply; 6+ messages in thread
From: Bernd Schmidt @ 2010-09-23 1:58 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: binutils
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
On 09/23/2010 01:18 AM, Joseph S. Myers wrote:
> Is it possible to test this in the linker testsuite? That is, can the bug
> be exercised starting with objects where each object only contains REL or
> only contains RELA relocations, or do you need a single input containing
> both (which the GNU assembler won't generate)? (Specify -mgenerate-rel in
> #source rather than #as in the .d file to have it apply only to some of
> the input files.) If it can be tested, a test should be added to
> ld-tic6x.
Here's a test I came up with, based on existing tests. It compiles the
first file with -mgenerate-rel; the first half of the regexps is copied
from one existing .d file and the second half from another. Ok?
Bernd
[-- Attachment #2: newtest.diff --]
[-- Type: text/plain, Size: 2605 bytes --]
Index: ld/testsuite/ld-tic6x/pcrel-reloc-local-r-rel-rela.d
===================================================================
RCS file: ld/testsuite/ld-tic6x/pcrel-reloc-local-r-rel-rela.d
diff -N ld/testsuite/ld-tic6x/pcrel-reloc-local-r-rel-rela.d
*** /dev/null 1 Jan 1970 00:00:00 -0000
--- ld/testsuite/ld-tic6x/pcrel-reloc-local-r-rel-rela.d 23 Sep 2010 01:55:34 -0000
***************
*** 0 ****
--- 1,62 ----
+ #name: C6X PC-relative relocations, local symbols, -r, mixed link of REL/RELA
+ #as: -mlittle-endian
+ #ld: -r -melf32_tic6x_le
+ #source: pcrel-reloc-local-1.s -mgenerate-rel
+ #source: pcrel-reloc-local-2.s
+ #objdump: -dr
+
+ .*: *file format elf32-tic6x-le
+
+
+ Disassembly of section \.text:
+
+ 0+ <[^>]*>:
+ [ \t]*0:[ \t]+00000000[ \t]+nop 1
+ [ \t]*4:[ \t]+00800162[ \t]+addkpc \.S2 0 <[^>]*>,b1,0
+ [ \t]*4: R_C6000_PCR_S7[ \t]+\.text\.1
+ [ \t]*8:[ \t]+00810162[ \t]+addkpc \.S2 4 <[^>]*>,b1,0
+ [ \t]*8: R_C6000_PCR_S7[ \t]+\.text\.1
+ [ \t]*c:[ \t]+00000012[ \t]+b \.S2 0 <[^>]*>
+ [ \t]*c: R_C6000_PCR_S21[ \t]+\.text\.1
+ [ \t]*10:[ \t]+00000092[ \t]+b \.S2 4 <[^>]*>
+ [ \t]*10: R_C6000_PCR_S21[ \t]+\.text\.1
+ [ \t]*14:[ \t]+00801022[ \t]+bdec \.S2 0 <[^>]*>,b1
+ [ \t]*14: R_C6000_PCR_S10[ \t]+\.text\.1
+ [ \t]*18:[ \t]+00803022[ \t]+bdec \.S2 4 <[^>]*>,b1
+ [ \t]*18: R_C6000_PCR_S10[ \t]+\.text\.1
+ [ \t]*1c:[ \t]+00000122[ \t]+bnop \.S2 0 <[^>]*>,0
+ [ \t]*1c: R_C6000_PCR_S12[ \t]+\.text\.1
+ [ \t]*20:[ \t]+00010122[ \t]+bnop \.S2 24 <[^>]*>,0
+ [ \t]*20: R_C6000_PCR_S12[ \t]+\.text\.1
+ [ \t]*\.\.\.
+ [ \t]*44:[ \t]+00000122[ \t]+bnop \.S2 40 <[^>]*>,0
+ [ \t]*44: R_C6000_PCR_S12[ \t]+\.text\.1\+0x20
+ [ \t]*48:[ \t]+00000122[ \t]+bnop \.S2 40 <[^>]*>,0
+ [ \t]*48: R_C6000_PCR_S12[ \t]+\.text\.1\+0x24
+ [ \t]*4c:[ \t]+00801022[ \t]+bdec \.S2 40 <[^>]*>,b1
+ [ \t]*4c: R_C6000_PCR_S10[ \t]+\.text\.1\+0x20
+ [ \t]*50:[ \t]+00801022[ \t]+bdec \.S2 40 <[^>]*>,b1
+ [ \t]*50: R_C6000_PCR_S10[ \t]+\.text\.1\+0x24
+ [ \t]*54:[ \t]+00000012[ \t]+b \.S2 40 <[^>]*>
+ [ \t]*54: R_C6000_PCR_S21[ \t]+\.text\.1\+0x20
+ [ \t]*58:[ \t]+00000012[ \t]+b \.S2 40 <[^>]*>
+ [ \t]*58: R_C6000_PCR_S21[ \t]+\.text\.1\+0x24
+ [ \t]*5c:[ \t]+00800162[ \t]+addkpc \.S2 40 <[^>]*>,b1,0
+ [ \t]*5c: R_C6000_PCR_S7[ \t]+\.text\.1\+0x20
+ [ \t]*60:[ \t]+00800162[ \t]+addkpc \.S2 60 <[^>]*>,b1,0
+ [ \t]*60: R_C6000_PCR_S7[ \t]+\.text\.1\+0x24
+ [ \t]*\.\.\.
+
+ Disassembly of section \.text\.1:
+
+ 0+ <[^>]*>:
+ [ \t]*0:[ \t]+00000000[ \t]+nop 1
+
+ 0+4 <[^>]*>:
+ [ \t]*\.\.\.
+
+ 0+20 <[^>]*>:
+ [ \t]*20:[ \t]+00000000[ \t]+nop 1
+
+ 0+24 <[^>]*>:
+ [ \t]*\.\.\.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: C6x: Fix another problem with rela. and rel. sections
2010-09-23 1:58 ` Bernd Schmidt
@ 2010-09-23 15:36 ` Joseph S. Myers
0 siblings, 0 replies; 6+ messages in thread
From: Joseph S. Myers @ 2010-09-23 15:36 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: binutils
On Thu, 23 Sep 2010, Bernd Schmidt wrote:
> On 09/23/2010 01:18 AM, Joseph S. Myers wrote:
>
> > Is it possible to test this in the linker testsuite? That is, can the bug
> > be exercised starting with objects where each object only contains REL or
> > only contains RELA relocations, or do you need a single input containing
> > both (which the GNU assembler won't generate)? (Specify -mgenerate-rel in
> > #source rather than #as in the .d file to have it apply only to some of
> > the input files.) If it can be tested, a test should be added to
> > ld-tic6x.
>
> Here's a test I came up with, based on existing tests. It compiles the
> first file with -mgenerate-rel; the first half of the regexps is copied
> from one existing .d file and the second half from another. Ok?
This test is OK.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: C6x: Fix another problem with rela. and rel. sections
2010-09-22 22:04 C6x: Fix another problem with rela. and rel. sections Bernd Schmidt
2010-09-22 23:18 ` Joseph S. Myers
@ 2010-10-01 13:47 ` Joseph S. Myers
2010-10-01 13:51 ` Bernd Schmidt
1 sibling, 1 reply; 6+ messages in thread
From: Joseph S. Myers @ 2010-10-01 13:47 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: binutils
On Thu, 23 Sep 2010, Bernd Schmidt wrote:
> TI's compiler for C6x produces both rel. and rela. sections. When compiling
> the kernel with it, we end up with rela.init.text and rel.init.text, and when
> we then try to use GNU ld to link these objects together using "-r", the
> linker aborts with
>
> ld: init/mounts.o: relocation size mismatch in init/do_mounts.o section .text
> ld: final link failed: File in wrong format
>
> That's because in the output we've only made one of the two sections. I
> looked around in other targets for ways to fix it, and came across a
> definition of elf_fake_sections in elf32-m32r.c. Adding such a function to
> elf32-tic6x.c seems to fix the problem.
>
> Ok?
This appears to have caused:
FAIL: ld-elf/64ksec-r
regexp "^There are 680.. section headers.*:$"
line "There are 102011 section headers, starting at offset 0x13e594:"
(Testing for cross to c6x-elf from i686-pc-linux-gnu. 2010-09-23 16:00:00
passes, 2010-09-23 17:00:00, this is the only commit in that interval.)
Please fix. When reviewing C6X patches I am presuming that they have been
tested not to cause regressions for a relevant target - did this failure
result from an interaction with another commit between when you tested the
patch and when you committed it?
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: C6x: Fix another problem with rela. and rel. sections
2010-10-01 13:47 ` Joseph S. Myers
@ 2010-10-01 13:51 ` Bernd Schmidt
0 siblings, 0 replies; 6+ messages in thread
From: Bernd Schmidt @ 2010-10-01 13:51 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: binutils
On 10/01/2010 03:47 PM, Joseph S. Myers wrote:
> This appears to have caused:
>
> FAIL: ld-elf/64ksec-r
>
> regexp "^There are 680.. section headers.*:$"
> line "There are 102011 section headers, starting at offset 0x13e594:"
>
> (Testing for cross to c6x-elf from i686-pc-linux-gnu. 2010-09-23 16:00:00
> passes, 2010-09-23 17:00:00, this is the only commit in that interval.)
>
> Please fix. When reviewing C6X patches I am presuming that they have been
> tested not to cause regressions for a relevant target - did this failure
> result from an interaction with another commit between when you tested the
> patch and when you committed it?
No, I probably forgot to run the testsuite. Sorry. I'm currently
working on the other rel/rela patch and will make sure it's fixed.
Bernd
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-10-01 13:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-22 22:04 C6x: Fix another problem with rela. and rel. sections Bernd Schmidt
2010-09-22 23:18 ` Joseph S. Myers
2010-09-23 1:58 ` Bernd Schmidt
2010-09-23 15:36 ` Joseph S. Myers
2010-10-01 13:47 ` Joseph S. Myers
2010-10-01 13:51 ` Bernd Schmidt
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).