Date: Fri, 12 May 2017 14:36:48 -0700 From: Mark Millard <markmi@dsl-only.net> To: bob prohaska <fbsd@www.zefox.net> Cc: ports@freebsd.org, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: www/firefox on RPI2: error: instruction requires: armv6t2 Message-ID: <B9B8FF42-BBEE-4E1B-9432-AFDCD88F2CCA@dsl-only.net> In-Reply-To: <20170512193131.GA79348@www.zefox.net> References: <20170509230236.GA69546@www.zefox.net> <CAJwjRmQiON9J8zZyb7ad5YNo7Ccrdwd0W%2B-6rqzwdcZp%2BEXv%2Bw@mail.gmail.com> <20170510151019.GA70628@www.zefox.net> <CAJwjRmTuXTcG2%2Bxm4tEwV6NRec9Y_kP62_Zza1=YQq508d0fFQ@mail.gmail.com> <20170511033754.GA74153@www.zefox.net> <3C56C526-24E4-45D4-B202-562BD7CB22C2@dsl-only.net> <80B1CCCF-A151-40B8-87D5-CADD513CFAAD@dsl-only.net> <20170512014441.GA77264@www.zefox.net> <85B88765-A708-414B-A465-14A044196D3D@dsl-only.net> <FD720BDC-3E69-4FC5-9C64-A46CBED4DB3F@dsl-only.net> <20170512193131.GA79348@www.zefox.net>
index | next in thread | previous in thread | raw e-mail
On 2017-May-12, at 12:31 PM, bob prohaska <fbsd@www.zefox.net> wrote:
> On Thu, May 11, 2017 at 08:14:14PM -0700, Mark Millard wrote:
>> Having -mcpu=cortex-a7 in ASFLAGS would contribute to
>> both of the examples.
>>
>
> Restarting the make with
> root@www:/usr/ports/www/firefox # make CFLAGS=-mcpu=cortex-a7 ASFLAGS=-mcpu=cortex-a7 -DBATCH > & make.log &
Again the commands might be handy, although in this
case the source code being assembled looks more
interesting.
> made considerably more progress, but compilation still stopped with errors
> of the form
> /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armSP_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S:129:9: error: unknown directive
Looking on the web the line 129 appears to be:
.macro FFTSTAGE scaled, inverse, name
It looks like /usr/bin/cc 's processing of .S assembler
notation does not support .macro (or the later .endm
I suppose).
This may mean that AS needs to be replaced so that
$(AS) picks a tool that has the support of the syntax.
Or may be cc needs use of -B to pick up some specific
toolchain's utilities that handle the .macro and its
use.
> /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armSP_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S:138:23: error: unexpected token in operand
This one looks to be for a line that looks like:
VMOV half, 0.5
where the earlier line 121 had:
#define half D13.F32
The normal form of this instruction might
be something like:
VMOV.F32 D13, #0.5
that encodes the element type/size in the
instruction, instead of in the operand.
I'm not sure. Also the immediate value
might need a # prefix.
But such claims may be tied to the parser
in the specific assembler-processing that
ends up involved. I do not know how
standardized the assembler notation(s) are
for the context.
> /usr/ports/www/firefox/work/firefox-53.0.2/media/openmax_dl/dl/sp/src/armSP_FFTInv_CCSToR_F32_preTwiddleRadix2_unsafe_s.S:152:14: error: invalid operand for instruction
This one looks to be for a line looking like:
VLD1 dX0,[pSrc],step
where prior lines had:
#define pSrc r0
. . .
#define step r8
. . .
#define dX0 D0.F32
The normal form of this instruction might
be something like:
VLD1.32 D0,[r0],r8
that encodes the element type/size in the
instruction (with the interleave pattern: 1)
instead of in the operand. I'm not sure.
But such claims may be tied to the parser
in the specific assembler-processing that
ends up involved. I do not know how
standardized the assembler notation(s) are
for the context.
> Make clean has been run and compilation started anew, using the same make
> command line, in the hope the mistake was one of consistency.
My guess from the above is that the problem will
repeat in this rebuild.
===
Mark Millard
markmi at dsl-only.net
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B9B8FF42-BBEE-4E1B-9432-AFDCD88F2CCA>