Portage visual --> gcc

Version imprimable

01/08/2005, 15h52
jeje99

Portage visual --> gcc
Bonjour,

Je suis en train de faire le portage d'une application conçu sous visual c++ sur le compilateur gcc. Cette application utilise l'option de compilation Zp2 de visual. Je n'arrive pas à trouver d'équivalent sous gcc : je n'ai pas envie de redéfinir toutes mes structures avec l'attribut.
Code:

1 2 __attribute((packed))__
Quelqu'un à t'il une solution ?
01/08/2005, 19h30
Matthieu Brucher

Tu as besoin de ça pour quoi ?
02/08/2005, 09h03
jeje99
Je vais donner un exemple :
Code:

1 2 3 4 5 6 typedef struct { int a; int b short c; } toto_t
Le compilateur traite les structures par packet de 4 octets ce qui fait que sans l'option Zp2, si je fais sizeof(toto_t) on me répond 12 alors que moi je veux que ce sois 10.

Dans gcc, la seule solution pour que j'ai trouvé est de rajouter __attribute((packed))__ à la fin de la définition de la structure :
Code:

1 2 3 4 5 6 typedef struct { int a; int b short c; } __attribute((packed))__ toto_t
Si il existe un autre opérateur que sizeof qui donne la taille d'une structure ça m'intéresse. Parce que maitenant que j'y refléchit je trouve ça bête de désoptimiser ma compilation juste pour avoir une valuer juste.
02/08/2005, 09h29
Emmanuel Delahaye
Citation:
Envoyé par jeje99

Je vais donner un exemple :

Code:

1 2 3 4 5 6 typedef struct { int a; int b short c; } toto_t

Le compilateur traite les structures par packet de 4 octets ce qui fait que sans l'option Zp2, si je fais sizeof(toto_t) on me répond 12 alors que moi je veux que ce sois 10.

Dans gcc, la seule solution pour que j'ai trouvé est de rajouter __attribute((packed))__ à la fin de la définition de la structure :

Code:

1 2 3 4 5 6 typedef struct { int a; int b short c; } __attribute((packed))__ toto_t

Si il existe un autre opérateur que sizeof qui donne la taille d'une structure ça m'intéresse. Parce que maitenant que j'y refléchit je trouve ça bête de désoptimiser ma compilation juste pour avoir une valuer juste.
Cette manip n'est pas du tout portable. Quel est le but de l'opération ?
- Si c'est pour 'gagner de la place', il y a d'autres moyens (champs de bits, par exemple).
- Si c'est pour mapper sur une structure d'octets (trames réseau etc.), c'est une erreur de conception.
02/08/2005, 09h45
jeje99

C'est pour mapper sur une structure d'octet (récupération de données dans un fichier).

Si je comprend bien les grandes têtes pensantes de mon entrprise n'ont pas bien fait leur travail. Donnons comme excuse que le code de base remonte à quelques années et que la notion de portabilité n'était pas encore d'une grande importance à l'époque (1997). Pour en revenir à mon problème, je ne peux absument pas modifier le fichier que je lis quelle solution me conseillez vous pour rendre ce code portable ?

Pour eviter l'ajout d'octets de padding, gcc propose l'option -fpack-struct. Cette option est disponible depuis au moins gcc 2.95.3.

Code:

1
2
3
4
5
 
-fpack-struct[=n]
    Without a value specified, pack all structure members together without holes. When a value is specified (which must be a small power of two), pack structure members according to this value, representing the maximum alignment (that is, objects with default alignment requirements larger than this will be output potentially unaligned at the next fitting location).
 
    Warning: the -fpack-struct switch causes GCC to generate code that is not binary compatible with code generated without that switch. Additionally, it makes the code suboptimal. Use it to conform to a non-default application binary interface.

02/08/2005, 10h39
Matthieu Brucher

Citation:

Envoyé par jeje99

C'est pour mapper sur une structure d'octet (récupération de données dans un fichier).

Si je comprend bien les grandes têtes pensantes de mon entrprise n'ont pas bien fait leur travail. Donnons comme excuse que le code de base remonte à quelques années et que la notion de portabilité n'était pas encore d'une grande importance à l'époque (1997). Pour en revenir à mon problème, je ne peux absument pas modifier le fichier que je lis quelle solution me conseillez vous pour rendre ce code portable ?

Exact, ces têtes pensantes n'ont pas pensé à la portabilité opu même le fait que le compilateur pouvait évoluer lui aussi !
Une solution sale serait de lire le fichier puis sauvegarder 10 octets par 10 octets - en espérant que l'ordre de la structure ne sera pas changée... -
02/08/2005, 13h22
jeje99

Vu ce qui est marqué dans le man de gcc à propos de -fpack-struct[=n]. Je pense que le mieux c'est je continue avec les __attribute((packed))__ que j'ajoute aux déclarations de mes structures.
02/08/2005, 14h03
Matthieu Brucher

Tu peux peut-être générer un convertisseur de fichiers avec cet attribut-là puis utiliser une version plus portable dans ton code - déjà ne pas utiliser de short par exemple - ? Ceci afin de répondre au point concernant la sous-optimimalité du code généré.
02/08/2005, 14h43
DaZumba

Citation:

Envoyé par jeje99

Vu ce qui est marqué dans le man de gcc à propos de -fpack-struct[=n].

Qu'est-ce qui te fais peur? Ca me semble la solution la plus proche de ta compilation Windows.
03/08/2005, 19h26
jeje99

C'est cette ligne qui me fait peur :

Code:

causes GCC to generate code that is not binary compatible with code generated without that switch

Je comprend pas tout mais j'ai l'impression que c'est pas top d'utiliser cette option. Et cet avertissement n'est pas donné pour l'utilisation de __attribute__((packed)). Enfin il est possible qu'il fasse la même chose quand même.
03/08/2005, 19h52
capitN.flam

Citation:

Envoyé par jeje99

C'est cette ligne qui me fait peur :

Code:

causes GCC to generate code that is not binary compatible with code generated without that switch

Je comprend pas tout mais j'ai l'impression que c'est pas top d'utiliser cette option. Et cet avertissement n'est pas donné pour l'utilisation de __attribute__((packed)). Enfin il est possible qu'il fasse la même chose quand même.

Si je comprends bien cette ligne: imaginons que tu as 2 fichiers c (f1.c et f2.c), tu compiles f1.c avec cette option de maniere a avoir f1.o et f2.c sans cette option de maniere a avoir f2.o. quand tu vas vouloir faire l'edition des liens entre f1.o et f2.o pour obtenir ton executable final tu ne pourras pas car ils ne sont pas compatible "binairement". Mais si tu compile toute ton application avec cette option il ne devrait pas y avoir de pb!