Problème d'alignement mémoire

On 2007-10-17, JKB <knatschke@koenigsberg.fr> wrote:

Le 17-10-2007, à propos de
Re: Problème d'alignement mémoire,
Marc Boyer écrivait dans fr.comp.lang.c :

Ce qui m'étonne, c'est qu'il plante dans l'affectation de p est pas
dans l'accès à *p.
Le memcpy que je propose résoudra la ligne d'affectation de p,
mais surement pas les accès par la suite.
Moi, je proposerais de changer le code en
u32 ncyl, toto;
memcpy(&toto, ptr+1, sizeof(toto) );

Je viens de mettre dans mon code :

q = (u32 *)(ptr + 1);
p = memcpy(p,ptr+1,sizeof(p));
printk("%p %pn", p, q);

simplement pour voir si les deux méthodes renvoient le même
résultat, et cela me donne :

Kernel unaligned access at TPC[1017417c] insert_geo_m_pg+0x84/0xa0 [iscsi_trgt]
Kernel unaligned access at TPC[10174184] insert_geo_m_pg+0x8c/0xa0 [iscsi_trgt]
fffff800f7d3e034 fffff800f7d3e035
Kernel unaligned access at TPC[1017417c] insert_geo_m_pg+0x84/0xa0 [iscsi_trgt]
Kernel unaligned access at TPC[10174184] insert_geo_m_pg+0x8c/0xa0 [iscsi_trgt]

Dans la suite, j'utilise q, parce que l'utilisation de p me renvoie
une double faute et je me retrouve avec le prompt de l'OBP...

Question certainement triviale. Pourquoi les deux valeurs sont-elles
différentes ?

Ben.. Si mes souvenirs sont bon, ton cast de prt+1, de type u8* en
un u32* est dépendant du compilo.

Tu veux pas faire un
printk("ptr=%p ptr+1=%p p=%p q=%pn", ptr, ptr+1, p, q);
dans ton code plutôt. Le fait que q soit sur une adresse impaire
me chagrine un peu.

Le 17-10-2007, à propos de
Re: Problème d'alignement mémoire,
Marc Boyer écrivait dans fr.comp.lang.c :

On 2007-10-17, JKB <knatschke@koenigsberg.fr> wrote:

Le 17-10-2007, à propos de
Re: Problème d'alignement mémoire,
Marc Boyer écrivait dans fr.comp.lang.c :

Ce qui m'étonne, c'est qu'il plante dans l'affectation de p est pas
dans l'accès à *p.
Le memcpy que je propose résoudra la ligne d'affectation de p,
mais surement pas les accès par la suite.
Moi, je proposerais de changer le code en
u32 ncyl, toto;
memcpy(&toto, ptr+1, sizeof(toto) );

Je viens de mettre dans mon code :

q = (u32 *)(ptr + 1);
p = memcpy(p,ptr+1,sizeof(p));
printk("%p %pn", p, q);

simplement pour voir si les deux méthodes renvoient le même
résultat, et cela me donne :

Kernel unaligned access at TPC[1017417c] insert_geo_m_pg+0x84/0xa0 [iscsi_trgt]
Kernel unaligned access at TPC[10174184] insert_geo_m_pg+0x8c/0xa0 [iscsi_trgt]
fffff800f7d3e034 fffff800f7d3e035
Kernel unaligned access at TPC[1017417c] insert_geo_m_pg+0x84/0xa0 [iscsi_trgt]
Kernel unaligned access at TPC[10174184] insert_geo_m_pg+0x8c/0xa0 [iscsi_trgt]

Dans la suite, j'utilise q, parce que l'utilisation de p me renvoie
une double faute et je me retrouve avec le prompt de l'OBP...

Question certainement triviale. Pourquoi les deux valeurs sont-elles
différentes ?

Ben.. Si mes souvenirs sont bon, ton cast de prt+1, de type u8* en
un u32* est dépendant du compilo.

Tu veux pas faire un
printk("ptr=%p ptr+1=%p p=%p q=%pn", ptr, ptr+1, p, q);
dans ton code plutôt. Le fait que q soit sur une adresse impaire
me chagrine un peu.

Moi aussi, comme le warning à la compilation :

/usr/src/iscsi/trunk/kernel/target_disk.c:75: warning: 'p' is used
uninitialized in this function

sur la ligne du memcpy().

Résultat :

ptrÿfff800f7d46034 ptr+1ÿfff800f7d46035 pÿfff800f7d46034 qÿfff800f7d46035
Kernel unaligned access at TPC[10174184] insert_geo_m_pg+0x8c/0xa0 [iscsi_trgt]
Kernel unaligned access at TPC[1017418c] insert_geo_m_pg+0x94/0xa0 [iscsi_trgt]
ptrÿfff800f7d08034 ptr+1ÿfff800f7d08035 pÿfff800f7d08034 qÿfff800f7d08035
Kernel unaligned access at TPC[10174184] insert_geo_m_pg+0x8c/0xa0 [iscsi_trgt]
Kernel unaligned access at TPC[1017418c] insert_geo_m_pg+0x94/0xa0 [iscsi_trgt]

Je sèche de plus en plus...

Oui, d'autant que je t'ai dis une énormité. Alors qu'on ait même pas
vendredi. Le
memcpy(p,ptr+1,sizeof(p));
ne correspond pas du tout à ce que tu veux faire. C'est un équivalent
(modulo les pb d'alignement) à
*p= *( (u32*) ptr+1 );
Et le compilo rale tout à fait a bon escient.

On reprend à 0. Tu as un code du genre
void foo(u8* ptr){
// Code actuel
u32* p;
p= (u32*) ptr+1;
// usage de *p
}
qui plante, ce qui me semble tout à fait normal.
La question à laquelle tu n'a pas répondu est: il plante dès
l'affectation, ou dès qu'on déréférence p (qu'on utilise *p) ?

Même s'il rale dès l'affectation, et qu'on arrive à le faire taire
à ce moment là, de toute façon, on ne pourra pas accéder à
(ptr+1) pour y stocker un u32 de manière transparente, à cause
des pb d'alignement.
La seule solution que je vois, c'est de déclarer une variable
u32, et de l'utiliser (voir mon autre post avec toto, ou celui
de Charlie avec n).

Le 17-10-2007, à propos de
Re: Problème d'alignement mémoire,
Marc Boyer écrivait dans fr.comp.lang.c :

Oui, d'autant que je t'ai dis une énormité. Alors qu'on ait même pas
vendredi. Le
memcpy(p,ptr+1,sizeof(p));
ne correspond pas du tout à ce que tu veux faire. C'est un équivalent
(modulo les pb d'alignement) à
*p= *( (u32*) ptr+1 );
Et le compilo rale tout à fait a bon escient.

On reprend à 0. Tu as un code du genre
void foo(u8* ptr){
// Code actuel
u32* p;
p= (u32*) ptr+1;
// usage de *p
}
qui plante, ce qui me semble tout à fait normal.
La question à laquelle tu n'a pas répondu est: il plante dès
l'affectation, ou dès qu'on déréférence p (qu'on utilise *p) ?

En fait, l'erreur est récupérée par le noyau, et je ne suis pas
capable de dire où celui-ci râle.

Même s'il rale dès l'affectation, et qu'on arrive à le faire taire
à ce moment là, de toute façon, on ne pourra pas accéder à
(ptr+1) pour y stocker un u32 de manière transparente, à cause
des pb d'alignement.
La seule solution que je vois, c'est de déclarer une variable
u32, et de l'utiliser (voir mon autre post avec toto, ou celui
de Charlie avec n).

Bon, je vais essayer la solution avec le n...

Le 17-10-2007, à propos de
Re: Problème d'alignement mémoire,
JKB écrivait dans fr.comp.lang.c :

Le 17-10-2007, à propos de
Re: Problème d'alignement mémoire,
Marc Boyer écrivait dans fr.comp.lang.c :

Oui, d'autant que je t'ai dis une énormité. Alors qu'on ait même pas
vendredi. Le
memcpy(p,ptr+1,sizeof(p));
ne correspond pas du tout à ce que tu veux faire. C'est un équivalent
(modulo les pb d'alignement) à
*p= *( (u32*) ptr+1 );
Et le compilo rale tout à fait a bon escient.

On reprend à 0. Tu as un code du genre
void foo(u8* ptr){
// Code actuel
u32* p;
p= (u32*) ptr+1;
// usage de *p
}
qui plante, ce qui me semble tout à fait normal.
La question à laquelle tu n'a pas répondu est: il plante dès
l'affectation, ou dès qu'on déréférence p (qu'on utilise *p) ?

En fait, l'erreur est récupérée par le noyau, et je ne suis pas
capable de dire où celui-ci râle.

Même s'il rale dès l'affectation, et qu'on arrive à le faire taire
à ce moment là, de toute façon, on ne pourra pas accéder à
(ptr+1) pour y stocker un u32 de manière transparente, à cause
des pb d'alignement.
La seule solution que je vois, c'est de déclarer une variable
u32, et de l'utiliser (voir mon autre post avec toto, ou celui
de Charlie avec n).

Bon, je vais essayer la solution avec le n...

J'arrive à ceci qui fonctionne :

u32 n;
memcpy(&n,ptr+1,sizeof(u32));
n = n | cpu_to_be32(ncyl);
memcpy(ptr+1, &n, sizeof(u32));

Le 17-10-2007, à propos de
Re: Problème d'alignement mémoire,
Marc Boyer écrivait dans fr.comp.lang.c :

On 2007-10-17, Charlie Gordon <news@chqrlie.org> wrote:

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le
message
de news: slrnfhbu0r.5nm.Marc.Boyer@ubu.enseeiht.fr...

On 2007-10-17, JKB <knatschke@koenigsberg.fr> wrote:

Le 17-10-2007, à propos de
J'essaye donc de
bricoler octet par octet pour réaligner tout cela par quelque chose
du genre de :

p = 0x0;
for(i = 0; i < 8; i++) p += ptr[i] << (8 * (7 - i));

qui ne fonctionne pas et je ne vois toujours pas pourquoi :-(

Ben, ptr[i] est un pointeur, donc une valeur sur 64 bits chez toi,
alors que j'imagine que tu voudrais récuperer 8 bits par 8 bits.
Donc, plutôt faire:
unsigned char char_ptr= (unsigned char*) ptr;
p= 0x0;
for(i= 0; i < 8 ; ++i)
p+= char_ptr[i] << (8 * (7-i) );
si on veut reprendre ton code (qui reste douteux).

Mais bon, pourquoi pas un memcpy ?

J'ai l'impression que vous etes sur une fausse piste: p = (u32*)(ptr +
1)
ne construit pas la valeur du pointeur p à partir des octets pointés par
ptr, mais à partir de la valeur de ptr. On ne sait pas quel est le type
de
ptr: supposons que c'est un pointeur sur u8, p pointerait alors sur un
entier stocké en mémoire aux adresses ptr+1, ptr+2, ptr+3, ptr+4. On ne
peut pas déréférencer (ptr+1) pour lire un u32 sur un Sun, mais on peut
lire
l'entier avec memcpy:

u32 n;
memcpy(&n, ptr + 1, sizeof(n));

Voui. Ce que je lui ai dit dans l'autre post.

Ouaips, memset est une bonne idée, mais ça coince toujours (les
résultats de q = (u32 *)(ptr + 1); et de memcpy(p,ptr+1,sizeof(p));
diffèrent de 1).

reste à gérer les problèmes d'endianness.

Tu veux dire quoi là ?

Je ne vois pas pourquoi il y aurait ici un tel problème...

Sparc64,
[Moi pas connaître, donc pas taper si c'est une ânerie]

pointeur 64 bits),
[bla bla bla]

istiod1(4534): Oops [#2]
TSTATE: 0000004480001603 TPC: 000000001017417c TNPC: 0000000010174180
^

Y: 00000000 Tainted: G D
TPC: <insert_geo_m_pg+0x84/0xa0 [iscsi_trgt]>