Discussion :

[alanglet]

Bonjour,

Je développe une petite application pour faire des requêtes sur une base de données Firebid 3 en utilisant des composants UIB.
Bien qu'utilisant Windows 10 64 bits, je l'ai d'abord développée sur une installation de Lazarus/FPC (les deux trunc début novembre)créée en version 32 bits avec fpcdeluxe fpcupdeluxe-i386-win32.exe. Ce dernier permettant d'installer le module de x86_64 pour windows, j'ai pu faire fonctionner sans problème mon application en 32b comme en 64b.
Désirant corriger FPC à causes certaines anomalies (fuites mémoires) gênantes pour d'autres applications, j'ai refait mon installation de Lazarus FPC dans les mêmes conditions. Pas de problème en 32b, mais lors de la compilation en 64b un message signale que le déguggeur ne fonctionnera pas.
J'ai donc refait l'installation de Lazarus/FPC en 64b avec fpcupdeluxe-x86_64-win64.exe et le module de cross-compilation i386 en 32b.
Mon application fonctionne très bien en 64b, mais en 32b, la lecture d'un champ de type timestamp provoque une erreur "Invalid floating point operation" lors de l'affichage suivi de l'affichage de la fenêtre assembleur jointe



Je suis loin d'être un spécialiste de l'assembleur, mais il me semble que les instructions comme "fild" sont spécifiques au 64b. Comme l'erreur semble bien apparaitre dans la procédure de sysutils concernant les timestamps, s'agit-il d'une erreur dans le module de cross-compilation et existe-t-il un moyen de la réparer?

André

[alanglet]

En attendant de trouver mieux, je me dépanne en réinstallant Lazarus/FPC en version 32 bits, avec cross-compilation en 64 bits. Mais pour débugger en 64 bits, je dois changer de débugger, GNU (gdb) heureusement encore livré, à la place de FpDebug installé par défaut.

André

[tourlourou]

Bonsoir,

Il serait intéressant de comparer les 2 codes asm 32 et 64 bits, alors que certaines au moins des instructions semblent exister pour les 2 mais pê avec des différences subtiles ?

[BeanzMaster]

Hello, ca serait bien d'avoir le code en pascal de la ou ca bloque. Utilises tu des variables de type "double" dans ton application ?

[alanglet]

Bonjour et merci de vous intéresser à ce problème.

Voici un tout petit programme qui met en évidence le problème: une simple application avec un bouton, et sur le OnClick du bouton le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
procedure TForm1.Button1Click(Sender:TObject);
var
  ts:TTimeStamp;
  ms:Comp;
begin
  ts:=DateTimeToTimeStamp(now);
  ms:=TimeStampToMSecs(ts);
  ShowMessage(DateTimeToStr(TimeStampToDateTime(ts)));
end;

On y retrouve la fonction de mon premier message, TimeStampToMSecs(ts) qui provoque l'erreur uniquement sur une installation de Lazarus 64b lors de la cross-compilation en 32b. Pas de problème si compilée en 64b sur cette installation ni sur une installation Lazarus 32b compilée en 32b ou cross-compilée en 64b.
Je n'ai pas trouvé la définition du type Comp résultat de cette fonction...
En plaçant un point d'arrêt dans la fenêtre assembleur ouverte dans la version 64->32, l'application s'arrêtera lors de la compilation 32->32 et si le fenêtre assembleur est ouverte, vous pouvez constater que le code est identique dans les 2 compilations en 32b. L'erreur doit être ailleurs... Contrairement à ce que je pensais, "fild" existe bien en 32b.

André

[BeanzMaster]

J'ai fais une petite recherche, il semblerai y avoir un bug avec la fonction TimeStampToMSecs pour la cross compilation en 32bits.
Le type comp est un alias pour int64
Il te faudras donc trouver une alternative peut-être avec les TDateTime ou de recoder toi même cette fonction

[alanglet]

Dans GitLab https://gitlab.com/freepascal.org/fp...-/issues/35147 le problème est connu depuis 3 ans, mais toujours pas résolu. Il est bien particulier à la cross-compilation depuis Win64.
Pour le moment il est préférable de ne pas utiliser cette cross-compilation si on utilise une base de données où le TDateTime est stockée sous le type TTimeStamp.
André