View Issue Details

IDProjectCategoryView StatusLast Update
0026555FPCCompilerpublic2018-02-08 19:02
ReporterMarco van de VoortAssigned ToMarco van de Voort 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionwon't fix 
Platformwin64OSOS Version
Product Version2.7.1Product Build 
Target VersionFixed in Version 
Summary0026555: Intel Asm reader allows inc qword ptr [global var]
DescriptionIntel Asm reader allows inc qword ptr [global var], this triggers linker warning

asmreaderbug.dpr(12,1) Warning: Object file "asmreaderbug.o" contains 32-bit absolute relocation to symbol ".bss.n_u_$p$

Steps To Reproducesee attached example
Additional InformationDistilled from forum thread,25373.0/topicseen.html
TagsNo tags attached.
Fixed in Revision
Attached Files


related to 0022665 closedJonas Maebe Can`t build shared library with RIP-relative addressing and Intel asm-syntax 


Marco van de Voort

2014-08-03 13:46


asmreaderbug.dpr (316 bytes)

Jonas Maebe

2014-08-03 13:57

manager   ~0076429

That warning simply means that the code is not position-independent. Other than that it's perfectly valid.

If you want the compiler to reject non-positition-independent assembler code, tell it to generate position-independent code via the -Cg switch.

Support for Intel-style x86-64 assembly is only available in svn trunk though. See the related bug report.

Jonas Maebe

2014-08-03 13:58

manager   ~0076430

And as I wrote a while ago on the MacPascal list:

How global variables have to be accessed on x86-64 differs amongst platforms and sometimes also depending on whether it's an exported variable (in the interface of a unit) or not (implementation or main program). I would strongly recommend against doing this.

Either rewrite the code in Pascal, or assign the global values you want to access first to local variables in Pascal code and then load those local variables from assembler code. Otherwise your code will end up in a huge mess of fragile ifdefs.

Jonas Maebe

2014-08-03 14:08

manager   ~0076431

Well, one addition: it does seem that on Win64 we don't give errors yet in all cases in the assembler reader where we should. The code should use [SHR_LL_LastTime + RIP] in both cases, even when not generating position-independent code. And apparently we don't give errors yet on Win64 even with -Cg.

My original remark stands though: do not use inline assembly on x86-64 to access global variables, unless you know the internal details of the ABI of every single OS you ever want to support.

Marco van de Voort

2014-08-03 15:34

manager   ~0076433

Then, is that documented?

Jonas Maebe

2014-08-03 15:45

manager   ~0076434

I consider that a given if you want to use assembly code on any platform (and I doubt the people that don't study the relevant ABIs right now will start doing it after we write that they should do so in the manual).

Marco van de Voort

2014-08-03 23:57

manager   ~0076438

I was more thinking that cause-effect is not always clear in these cases. Anyway, let's just close.

Issue History

Date Modified Username Field Change
2014-08-03 13:46 Marco van de Voort New Issue
2014-08-03 13:46 Marco van de Voort File Added: asmreaderbug.dpr
2014-08-03 13:57 Jonas Maebe Note Added: 0076429
2014-08-03 13:57 Jonas Maebe Status new => resolved
2014-08-03 13:57 Jonas Maebe Resolution open => no change required
2014-08-03 13:57 Jonas Maebe Assigned To => Jonas Maebe
2014-08-03 13:57 Jonas Maebe Relationship added related to 0022665
2014-08-03 13:58 Jonas Maebe Note Added: 0076430
2014-08-03 14:08 Jonas Maebe Note Added: 0076431
2014-08-03 14:08 Jonas Maebe Status resolved => new
2014-08-03 14:08 Jonas Maebe Resolution no change required => open
2014-08-03 14:08 Jonas Maebe Assigned To Jonas Maebe =>
2014-08-03 15:34 Marco van de Voort Note Added: 0076433
2014-08-03 15:45 Jonas Maebe Note Added: 0076434
2014-08-03 23:57 Marco van de Voort Note Added: 0076438
2014-08-03 23:57 Marco van de Voort Status new => resolved
2014-08-03 23:57 Marco van de Voort Resolution open => won't fix
2014-08-03 23:57 Marco van de Voort Assigned To => Marco van de Voort
2018-02-08 19:02 Marco van de Voort Status resolved => closed