This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Finding BFD bug
- From: pladow at pullman dot com
- To: binutils at sources dot redhat dot com
- Date: Fri, 11 Jun 2004 00:27:16 GMT
- Subject: Re: Finding BFD bug
> "Dave Korn" <dk@artimi.com> writes:
> > > > It suggests that the src_mask field should be 0 rather than
> > > > 0xffffffff.
> > > >
> > > > Ian
> > >
> > >
> > > Shouldn't partial_inplace be false as well, since the comment seems to
> > > indicate that we're on a RELA target here? Overall it looks like a
> > > REL-vs-RELA inconsistency between the linker and the assembler to me.
> >
> > Well, both changes fixed the problem! I just hope it doesn't break
> > anything else...
Well, my above statement has been proven wrong. The changes to src_msk and
partial_inplace fixed the external symbol problem. Now a problem appears in
the opposite case: local symbols (which worked before). Now all local
symbols have their offsets zerod. Again, this only happens in the data
section. Any references to symbols, local or external, are fine in the text
section.
> If "make check" returns identical results before and after the change, you
> can be fairly confident that the basic linker functionality is still sound.
This succeeded with the change. Though we are generating a set of cross
tools, so I don't know what kind of tests are done.
Mentioned earlier was that tc_gen_reloc should be tweaked. Looking in tc-
microblaze.c, they have the following code:
arelent *
tc_gen_reloc (section, fixp)
asection * section ATTRIBUTE_UNUSED;
fixS * fixp;
{
arelent * rel;
bfd_reloc_code_real_type code;
switch (fixp->fx_r_type)
{
case BFD_RELOC_NONE:
case BFD_RELOC_MICROBLAZE_64_NONE:
case BFD_RELOC_32:
case BFD_RELOC_MICROBLAZE_32_LO:
case BFD_RELOC_MICROBLAZE_32_LO_PCREL:
case BFD_RELOC_RVA:
case BFD_RELOC_64:
case BFD_RELOC_64_PCREL:
case BFD_RELOC_MICROBLAZE_32_ROSDA:
case BFD_RELOC_MICROBLAZE_32_RWSDA:
case BFD_RELOC_MICROBLAZE_32_SYM_OP_SYM:
code = fixp->fx_r_type;
break;
default:
printf("Got a reloc of size %d and pcrel %d\n", fixp->fx_size, fixp-
>fx_pcrel);
switch (F (fixp->fx_size, fixp->fx_pcrel))
{
MAP (1, 0, BFD_RELOC_8);
MAP (2, 0, BFD_RELOC_16);
MAP (4, 0, BFD_RELOC_32);
MAP (1, 1, BFD_RELOC_8_PCREL);
MAP (2, 1, BFD_RELOC_16_PCREL);
MAP (4, 1, BFD_RELOC_32_PCREL);
default:
code = fixp->fx_r_type;
as_bad (_("Can not do %d byte %srelocation"),
fixp->fx_size,
fixp->fx_pcrel ? _("pc-relative") : "");
}
break;
}
rel = (arelent *) xmalloc (sizeof (arelent));
rel->sym_ptr_ptr = (asymbol **) xmalloc (sizeof (asymbol *));
if (code == BFD_RELOC_MICROBLAZE_32_SYM_OP_SYM)
*rel->sym_ptr_ptr = symbol_get_bfdsym (fixp->fx_subsy);
else
*rel->sym_ptr_ptr = symbol_get_bfdsym (fixp->fx_addsy);
rel->address = fixp->fx_frag->fr_address + fixp->fx_where;
/* Always pass the addend along! */
rel->addend = fixp->fx_addnumber;
rel->howto = bfd_reloc_type_lookup (stdoutput, code);
if (rel->howto == NULL)
{
as_bad_where (fixp->fx_file, fixp->fx_line,
_("Cannot represent relocation type %s"),
bfd_get_reloc_code_name (code));
/* Set howto to a garbage value so that we can keep going.*/
rel->howto = bfd_reloc_type_lookup (stdoutput, BFD_RELOC_32);
assert (rel->howto != NULL);
}
return rel;
}
Given a cursory glance, does anyone see any issues?
Also, here are the objdump -r outputs for the two cases
Internal symbols:
$ mb-objdump -r main.o
main.o: file format elf32-microblaze
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000000 R_MICROBLAZE_64 .data
RELOCATION RECORDS FOR [.data]:
OFFSET TYPE VALUE
00000018 R_MICROBLAZE_32 .data
0000001c R_MICROBLAZE_32 .data
00000020 R_MICROBLAZE_32 .data
External symbols:
$ mb-objdump -r ../separate_files/main.o
./separate_files/main.o: file format elf32-microblaze
RELOCATION RECORDS FOR [.data]:
OFFSET TYPE VALUE
00000000 R_MICROBLAZE_32 test
00000004 R_MICROBLAZE_32 test+0x00000004
00000008 R_MICROBLAZE_32 test+0x00000008
Thanks,
Pete LaDow
---------------------------------------------
This message was sent by First Step Internet.
http://www.fsr.net/