[PATCH] [PowerPC] VLE update

[Alexander Fedotov]

>> If you split off the part dealing with SEC_PPC_VLE that can be
>> committed separately.

Done. New patch attached.


>> OK, but if there was a processor that could operate in both VLE and
>> non-VLE mode (controlled by MAS2 bit VLE), would these instructions be
>> available in both modes?  If only VLE, then SHF_PPC_VLE ought to be
>> set for any section containing them.  See tc-ppc.c:3513.
>>
>> However, from the fact that the "Lightweight Signal Processing APU
>> (LSP APU) Reference Manual" does not mention VLE, and the encoding of
>> these instructions, my guess is that these instruction are not VLE and
>> thus should not be in vle_opcodes.

Yes, there could be e.g e200z759n core. But it has SPE, not LSP.

On Tue, Aug 29, 2017 at 9:17 AM, Alan Modra <amodra@gmail.com> wrote:
> On Mon, Aug 28, 2017 at 05:20:45PM +0300, Alexander Fedotov wrote:
>> > 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.
>>
>> Okay, so I will set
>> +#define SEC_PPC_VLE SEC_MEP_VLIW
>
> If you split off the part dealing with SEC_PPC_VLE that can be
> committed separately.
>
>> > 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.
>>
>> Nope, they are not defined by ABI at all. I agree it would be better
>> to rework. I will remove it from current patch set.
>
> I should note that I'm not greatly concerned about adding relocations
> that aren't described in an ABI document.  It's not ideal, but the
> document can always be modified later.  I was more concerned that
> someone may have already described R_PPC_PLTREL24 as behaving
> differently for VLE, and the problem that causes for compatibility if
> the GNU toolchain then goes off and implements something else.
>
>> > 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?
>>
>> I see that LSP instructions are available only on the cores with VLE ISA only.
>
> OK, but if there was a processor that could operate in both VLE and
> non-VLE mode (controlled by MAS2 bit VLE), would these instructions be
> available in both modes?  If only VLE, then SHF_PPC_VLE ought to be
> set for any section containing them.  See tc-ppc.c:3513.
>
> However, from the fact that the "Lightweight Signal Processing APU
> (LSP APU) Reference Manual" does not mention VLE, and the encoding of
> these instructions, my guess is that these instruction are not VLE and
> thus should not be in vle_opcodes.
>
> --
> Alan Modra
> Australia Development Lab, IBM



-- 
Best regards,
AF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Missing-relocation-R_PPC_VLE_ADDR20.-Add-VLE-flag-to.patch
Type: text/x-patch
Size: 8217 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20170830/52e73c09/attachment.bin>