Assembling errors: bad instruction and size errors.
lazarus / 23-Operating Systems

----------------------------------------------------------------------
DonaldShimoda · 2019-09-02 23:39

Seems like the assembler generated a line exceding 256 chars and fails
building for raspberry pi arm.
there's any way to extend the size allowed for a single line?

PROJECT\lib\arm-linux\BasicServicesSchemaClient_Intf.s:86470: Error:
bad instruction `wrpr_$basicservicesschemaclient_intf_$$_tsesiones_his
torico_clientes_webdatatablerules_$_isesiones_historico_clientes_web_$
_33_$_basicservicesschemaclient_intf$_$tsesiones_historico_clientes_we
bdatatablerules_$__$$_getid_sesiones_historico_webvalue$$ansis'


PROJECT\lib\arm-linux\BasicServicesSchemaClient_Intf.s: Error: .size
expression for WRPR_$BASICSERVICESSCHEMACLIENT_INTF_$$_TSESIONES_HISTO
RICO_CLIENTES_WEBDATATABLERULES_$_ISESIONES_HISTORICO_CLIENTES_WEB_$_3
3_$_BASICSERVICESSCHEMACLIENT_INTF$_$TSESIONES_HISTORICO_CLIENTES_WEBD
ATATABLERULES_$__$$_GETID_SESIONES_HISTORICO_WEBVALUE$$ANSIS does not
evaluate to a constant

----------------------------------------------------------------------
Thaddy · 2019-09-03 07:06

I do not have the problem, compiling trunk with bog standard English,
but it looks like a natural language issue. I would report it as a
bug, but do not forget to describe the natural language you are using.
(I compile FPC trunk daily for RPi 3/4 and less regularly for older
Pi's or RPi zero's)

----------------------------------------------------------------------
marcov · 2019-09-03 08:36

That could be, the assembler readers date from a period  when there
was a lot of shortstring use.

If not trunk, then test trunk, and file a bug otherwise, preferably
with an example (e.g. of code that generates such long symbols)

----------------------------------------------------------------------
DonaldShimoda · 2019-09-03 12:47

Thanks Marco, will try with trunk fpc.

----------------------------------------------------------------------
DonaldShimoda · 2019-09-03 13:10

Quote from: Thaddy on September 03, 2019, 09:06:27 amI do not have the
problem, compiling trunk with bog standard English, but it looks like
a natural language issue. I would report it as a bug, but do not
forget to describe the natural language you are using.
(I compile FPC trunk daily for RPi 3/4 and less regularly for older
Pi's or RPi zero's)

BTW, I don't believe is a language issue, as Marco pointed is a
shortstring usage problem in the assembly chain. The problem is that
units is autogenerated and procedure names are really big.

Im testing trunk and comeback.

Best regards.

----------------------------------------------------------------------
Thaddy · 2019-09-03 13:53

Quote from: DonaldShimoda on September 03, 2019, 03:10:44 pmBTW, I
don't believe is a language issue, as Marco pointed is a shortstring
usage problem in the assembly chain. The problem is that units is
autogenerated and procedure names are really big.
It is a natural language issue, because e.g. Spanish or Portuguese,
but also under circumstances languages like French, Italian, Dutch or
German, are - way - more verbose than English and therefor run out of
shortstring space much earlier.
Marco seems to agree with me and understood what I was pointing at.
That also means it is a shortstring issue, but revealed by the issue
as I explained.
Not a minor issue, since it requires a string type change in the
compiler to be fixed properly.

----------------------------------------------------------------------
DonaldShimoda · 2019-09-03 18:16

If an English speaker named variables and procedures in a very very
detailed way... will have the same problem...  Not a natural language
issue at all. 
Let´s concentrate in the real problem.

BTW, can't  test In trunk compiler yet.Will try tomorrow.

----------------------------------------------------------------------
Thaddy · 2019-09-03 18:27

Quote from: DonaldShimoda on September 03, 2019, 08:16:12 pmIf an
English speaker named variables and procedures in a very very detailed
way... will have the same problem...  Not a natural language issue at
all. 
Let´s concentrate in the real problem.

BTW, can't  test In trunk compiler yet.Will try tomorrow.
Well it surfaced it.
I wrote:
"Not a minor issue, since it requires a string type change in the
compiler to be fixed properly."