This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] [PowerPC] VLE update
- From: Alan Modra <amodra at gmail dot com>
- To: Alexander Fedotov <alfedotov at gmail dot com>
- Cc: binutils at sourceware dot org
- Date: Mon, 28 Aug 2017 22:44:26 +0930
- Subject: Re: [PATCH] [PowerPC] VLE update
- Authentication-results: sourceware.org; auth=none
- References: <CAN8C2CrG3n5QP17Om=_0SwmLVOKi+Z9NV-oTKXsgnhhGd=N7cQ@mail.gmail.com> <20170827223428.GY3368@bubble.grove.modra.org> <CAN8C2CoL=Q+qbeYmFKScDR0ZihnEsrANYoy_qOF+QYUYV+eqfw@mail.gmail.com>
On Mon, Aug 28, 2017 at 01:11:28PM +0300, Alexander Fedotov wrote:
> >> + /* PowerPC VLE code. */
> >> +#define SEC_PPC_VLE 0x100000000
> >
> > How can this possibly work? The field is an unsigned int.
>
> You are right. In original patch it was just reuse:
> +#define SEC_PPC_VLE SEC_TIC54X_BLOCK
>
> Well what the best way to deal with this ? Extend flagword to long ?
> Or keep reuse ?
You could reuse the SEC_MEP_VLIW bit, I guess. The section flags
weren't really supposed to be used for target-specific purposes, but
it seems pointless trying to be a purist now.
>
>
> >> + (R_PPC_VLE_PLTREL24): New relocation.
> >> + (R_PPC_VLE_ADDR20): Likewise.
> >
> >How are these generated? I see code that processes them, but nothing
> > to create them.
>
> Regarding to R_PPC_VLE_PLTREL24 I forgot to apply patch:
>
> @@ -9686,8 +9845,17 @@ ppc_elf_relocate_section (bfd *output_bfd,
> }
> }
> else
> - r = _bfd_final_link_relocate (howto, input_bfd, input_section, contents,
> + {
> + if ((elf_section_flags (input_section) & SHF_PPC_VLE) != 0)
> + {
> + if (howto == ppc_elf_howto_table[R_PPC_PLTREL24])
> + howto = ppc_elf_howto_table[R_PPC_VLE_PLTREL24];
> + else if (howto == ppc_elf_howto_table[R_PPC_LOCAL24PC])
> + howto = ppc_elf_howto_table[R_PPC_VLE_REL24];
> + }
> + r = _bfd_final_link_relocate (howto, input_bfd,
> input_section, contents,
> rel->r_offset, relocation, addend);
> + }
That doesn't look elegant at all. So you are using R_PPC_PLTREL24 and
R_PPC_LOCAL24PC relocations in VLE code but giving them a new meaning.
Is that documented in the ABI?
I think it would be better to define new R_PPC_VLE_PLTREL24 and
R_PPC_VLE_LOCAL24 relocs, and make the assembler generate them when
assembling VLE code.
> Yes, R_PPC_VLE_ADDR20 is not used yet. But it is defined by Power
> Architecture 32-bit Application Binary Interface Supplement 1.0 -
> Linux & Embedded. So it looks like just missing.
OK.
> >> @@ -253,12 +253,13 @@ get_powerpc_dialect (struct disassemble_info *info)
> >> dialect = POWERPC_DIALECT (info);
> >>
> >> /* Disassemble according to the section headers flags for VLE-mode. */
> >> - if (dialect & PPC_OPCODE_VLE
> >> - && info->section != NULL && info->section->owner != NULL
> >> + if (dialect & PPC_OPCODE_VLE)
> >> + return dialect;
> >> + else if (info->section != NULL && info->section->owner != NULL
> >> && bfd_get_flavour (info->section->owner) == bfd_target_elf_flavour
> >> && elf_object_id (info->section->owner) == PPC32_ELF_DATA
> >> && (elf_section_flags (info->section) & SHF_PPC_VLE) != 0)
> >> - return dialect;
> >> + return PPC_OPCODE_VLE;
> >> else
> >> return dialect & ~ PPC_OPCODE_VLE;
> >
> >Can you explain why this change is necessary?
>
> As I can see it resolves problem with LSP disassembling on lsp.s test.
> Unfortunately I have no more history for this one. Drop it from the
> patch ?
As I understand it, SHF_PPC_VLE and PF_PPC_VLE are set on sections or
segments containing instructions that can only be executed by a
processor in VLE mode. PPC_OPCODE_VLE is set for such opcodes too.
So, do the LSP instructions only execute in VLE mode? I suspect not,
from their encoding.
Do you have the LSP instructions in the correct opcode table?
--
Alan Modra
Australia Development Lab, IBM