Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
Manuel Pégourié-Gonnard écrivait :
Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
Manuel Pégourié-Gonnard <mpg@elzevir.fr> écrivait :
Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
Manuel Pégourié-Gonnard écrivait :
Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
Le Mon, 21 Oct 2013 13:55:44 +0200,
Erwan David écrivait :Manuel Pégourié-Gonnard écrivait :
Bonjour,Bonjour,
Je suis désolé de poster ici une question qui n'est que margi nalement en
lien avec le langage C, mais comme il s'agit de portabilité qui es t un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mém oire ne
respectant pas certaines conditions d'alignement (par exemple, accà ¨s Ã
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouen t ?
sparc, 68000 je crois.
MIPS, Alpha (mais c'est mort) et en règle générale les pr ocesseurs
RISC qui aiment assez les BUS ERROR.
Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Le Mon, 21 Oct 2013 13:55:44 +0200,
Erwan David <erwan@rail.eu.org> écrivait :
Manuel Pégourié-Gonnard <mpg@elzevir.fr> écrivait :
Bonjour,
Bonjour,
Je suis désolé de poster ici une question qui n'est que margi nalement en
lien avec le langage C, mais comme il s'agit de portabilité qui es t un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mém oire ne
respectant pas certaines conditions d'alignement (par exemple, accà ¨s Ã
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouen t ?
sparc, 68000 je crois.
MIPS, Alpha (mais c'est mort) et en règle générale les pr ocesseurs
RISC qui aiment assez les BUS ERROR.
Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Le Mon, 21 Oct 2013 13:55:44 +0200,
Erwan David écrivait :Manuel Pégourié-Gonnard écrivait :
Bonjour,Bonjour,
Je suis désolé de poster ici une question qui n'est que margi nalement en
lien avec le langage C, mais comme il s'agit de portabilité qui es t un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mém oire ne
respectant pas certaines conditions d'alignement (par exemple, accà ¨s Ã
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouen t ?
sparc, 68000 je crois.
MIPS, Alpha (mais c'est mort) et en règle générale les pr ocesseurs
RISC qui aiment assez les BUS ERROR.
Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Manuel Pégourié-Gonnard écrivait :Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
Manuel Pégourié-Gonnard <mpg@elzevir.fr> écrivait :
Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
Manuel Pégourié-Gonnard écrivait :Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
JKB writes:Le Mon, 21 Oct 2013 13:55:44 +0200,
Erwan David écrivait :Manuel Pégourié-Gonnard écrivait :
Bonjour,Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
MIPS, Alpha (mais c'est mort) et en règle générale les processeurs
RISC qui aiment assez les BUS ERROR.
Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Il y a bien un mode qui permet de faire ca. De memoire, il etait
impossible a utiliser en pratique parce que la lib standard et les
autres lib de l'OS utilisent les acces non alignes donc foirent
joyeusement meme si ton code n'a pas de probleme.
JKB <jkb@koenigsberg.invalid> writes:
Le Mon, 21 Oct 2013 13:55:44 +0200,
Erwan David <erwan@rail.eu.org> écrivait :
Manuel Pégourié-Gonnard <mpg@elzevir.fr> écrivait :
Bonjour,
Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
MIPS, Alpha (mais c'est mort) et en règle générale les processeurs
RISC qui aiment assez les BUS ERROR.
Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Il y a bien un mode qui permet de faire ca. De memoire, il etait
impossible a utiliser en pratique parce que la lib standard et les
autres lib de l'OS utilisent les acces non alignes donc foirent
joyeusement meme si ton code n'a pas de probleme.
JKB writes:Le Mon, 21 Oct 2013 13:55:44 +0200,
Erwan David écrivait :Manuel Pégourié-Gonnard écrivait :
Bonjour,Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
MIPS, Alpha (mais c'est mort) et en règle générale les processeurs
RISC qui aiment assez les BUS ERROR.
Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Il y a bien un mode qui permet de faire ca. De memoire, il etait
impossible a utiliser en pratique parce que la lib standard et les
autres lib de l'OS utilisent les acces non alignes donc foirent
joyeusement meme si ton code n'a pas de probleme.
On 2013-10-21, Jean-Marc Bourguet wrote:JKB writes:Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Il faut armer le bit 18 du registre eflags. Une telle séquence peut
être (sous gcc, ou sous clang) :
__asm__("pushfnorl $0x40000,(%esp)npopf");
On 2013-10-21, Jean-Marc Bourguet wrote:
JKB <jkb@koenigsberg.invalid> writes:
Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Il faut armer le bit 18 du registre eflags. Une telle séquence peut
être (sous gcc, ou sous clang) :
__asm__("pushfnorl $0x40000,(%esp)npopf");
On 2013-10-21, Jean-Marc Bourguet wrote:JKB writes:Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Il faut armer le bit 18 du registre eflags. Une telle séquence peut
être (sous gcc, ou sous clang) :
__asm__("pushfnorl $0x40000,(%esp)npopf");
Manuel Pégourié-Gonnard écrivait :Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
Manuel Pégourié-Gonnard<mpg@elzevir.fr> écrivait :
Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
Manuel Pégourié-Gonnard écrivait :Bonjour,
Je suis désolé de poster ici une question qui n'est que marginalement en
lien avec le langage C, mais comme il s'agit de portabilité qui est un
des objectifs du C, et que la question ne se poserait pas dans d'autres
langages...
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
Bruno Ducrot écrivit :On 2013-10-21, Jean-Marc Bourguet wrote:JKB writes:Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Il faut armer le bit 18 du registre eflags. Une telle séquence peut
être (sous gcc, ou sous clang) :
__asm__("pushfnorl $0x40000,(%esp)npopf");
Il faut aussi que le processeur soit dans le mode où cela a un effet,
c'est-à-dire que le bit 18 (AM, même place) du registre CR0 soit armé.
En toute logique, pour un système normal le bit CR0.AM devrait être
désarmé, sinon c'est trop facile pour du code utilisateur de créer un
piège système imparable (ou à tout le moins de forcer un détour par
l'INT 0x17 à chaque accès mémoire).
Et tout aussi logiquement, l'accès à
CR0 est réservé au système (ring 0, kernel, etc.)
Bruno Ducrot écrivit :
On 2013-10-21, Jean-Marc Bourguet wrote:
JKB <jkb@koenigsberg.invalid> writes:
Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Il faut armer le bit 18 du registre eflags. Une telle séquence peut
être (sous gcc, ou sous clang) :
__asm__("pushfnorl $0x40000,(%esp)npopf");
Il faut aussi que le processeur soit dans le mode où cela a un effet,
c'est-à-dire que le bit 18 (AM, même place) du registre CR0 soit armé.
En toute logique, pour un système normal le bit CR0.AM devrait être
désarmé, sinon c'est trop facile pour du code utilisateur de créer un
piège système imparable (ou à tout le moins de forcer un détour par
l'INT 0x17 à chaque accès mémoire).
Et tout aussi logiquement, l'accès à
CR0 est réservé au système (ring 0, kernel, etc.)
Bruno Ducrot écrivit :On 2013-10-21, Jean-Marc Bourguet wrote:JKB writes:Sur x86, j'ai souvenir d'avoir vu un bout de code assembleur
permettant de "sigbusser" comme un sparc (gcc). Il suffisait
d'exécuter la séquence au début du programme.
Il faut armer le bit 18 du registre eflags. Une telle séquence peut
être (sous gcc, ou sous clang) :
__asm__("pushfnorl $0x40000,(%esp)npopf");
Il faut aussi que le processeur soit dans le mode où cela a un effet,
c'est-à-dire que le bit 18 (AM, même place) du registre CR0 soit armé.
En toute logique, pour un système normal le bit CR0.AM devrait être
désarmé, sinon c'est trop facile pour du code utilisateur de créer un
piège système imparable (ou à tout le moins de forcer un détour par
l'INT 0x17 à chaque accès mémoire).
Et tout aussi logiquement, l'accès à
CR0 est réservé au système (ring 0, kernel, etc.)
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
De mémoire, le 68000 génère une exception quand cela se produit. Le
système, s'il le souhaite, peut détourner le vecteur d'interruption
correspondant et faire les corrections nécessaires pour que cela
fonctionne de manière transparente.
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
De mémoire, le 68000 génère une exception quand cela se produit. Le
système, s'il le souhaite, peut détourner le vecteur d'interruption
correspondant et faire les corrections nécessaires pour que cela
fonctionne de manière transparente.
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
De mémoire, le 68000 génère une exception quand cela se produit. Le
système, s'il le souhaite, peut détourner le vecteur d'interruption
correspondant et faire les corrections nécessaires pour que cela
fonctionne de manière transparente.
Alexandre Bacquart écrivit :Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
De mémoire, le 68000 génère une exception quand cela se produit. Le
système, s'il le souhaite, peut détourner le vecteur d'interruption
correspondant et faire les corrections nécessaires pour que cela
fonctionne de manière transparente.
De mémoire (c'est trèèèèès loin pour moi) le 68000 de base ne sait pas
reprendre complètement une instruction interrompue, ce qui complique
notablement ce genre de procédure. Avec un 68010, par contre, ce doit
être possible (et long, et pas souvent implanté dans le système).
Alexandre Bacquart écrivit :
Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
De mémoire, le 68000 génère une exception quand cela se produit. Le
système, s'il le souhaite, peut détourner le vecteur d'interruption
correspondant et faire les corrections nécessaires pour que cela
fonctionne de manière transparente.
De mémoire (c'est trèèèèès loin pour moi) le 68000 de base ne sait pas
reprendre complètement une instruction interrompue, ce qui complique
notablement ce genre de procédure. Avec un 68010, par contre, ce doit
être possible (et long, et pas souvent implanté dans le système).
Alexandre Bacquart écrivit :Qu'y a-t-il comme architecture courante où les accès mémoire ne
respectant pas certaines conditions d'alignement (par exemple, accès à
un uint32_t pas aligné sur une frontière de 4 octets (oui, je sais,
uint32_t c'est pas portable, c'était pour l'exemple)) échouent ?
sparc, 68000 je crois.
De mémoire, le 68000 génère une exception quand cela se produit. Le
système, s'il le souhaite, peut détourner le vecteur d'interruption
correspondant et faire les corrections nécessaires pour que cela
fonctionne de manière transparente.
De mémoire (c'est trèèèèès loin pour moi) le 68000 de base ne sait pas
reprendre complètement une instruction interrompue, ce qui complique
notablement ce genre de procédure. Avec un 68010, par contre, ce doit
être possible (et long, et pas souvent implanté dans le système).