meuh31 a écrit 15 commentaires

  • [^] # Re: LLVM IR n'est pas portable

    Posté par  . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 1.

    Je crois que tu n'as pas vraiment compris le problème. Si dans l'ir tu lui donnes un "i32*" ou "i8*" alors llc à la compilation demande aux classes qui encapsulent les target-datalayout quelle est la taille d'un pointeur.
    Et effectivement en changeant l'architecture avec -march=XXX, tu changes le target-datalayout utilisé.
    Le problème vient du fait qu'un "long" (le type c) n'a pas la même taille sur 32 et 64 bits.

    Si tu prends le code suivant :

    int main() {
    printf("%d\n", sizeof(long)/sizeof(int));
    }

    Sur 32 bits tu vas avoir le résultat "1" sur 64 bits le résultat sera "2".

    En générant l'ir, clang | opt résumera l'appel à
    printf("%d\n" , 1); sur 32 bits
    et
    printf("%d\n" , 2); sur 64 bits

    Donc clang lors de la génération de l'ir prend les dimensions de la plateforme (long=4 ou long=8) et génère l'ir. Ca veut dire que l'ir qu'il soit généré avec clang sur 32 ou 64 bits n'aura pas la même tête si il y a des "long" ou autres trucs de ce genre dans ton code.

    Le premier exemple que j'ai donné est un bon exemple : il est portable en c et pas en llvm.
  • [^] # Re: LLVM IR n'est pas portable

    Posté par  . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 3.

    Parce que c'est une notion subjective ?
    Cela dit 42 convient. (forcément).
  • [^] # Re: LLVM IR n'est pas portable

    Posté par  . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 1.

    Ce bout de code en c est portable. Il marchera sur x86 _et_ sur x86_64.
    si tu fais un gcc ir.c sur 32 bits le code généré fonctionnera exactement de la même façon que si tu faisais un gcc ir.c sur 64 bits. C'est donc du code portable.

    Par contre si tu prends ton ir.bc que tu l'exécutes sur 64 bits, ça va être bizarre : le bytecode lui n'est pas portable.

    Ce code est pas particulièrement sale, le cast d'un pointeur en long est chose commune (par exemple gestion mémoire du kernel).
  • [^] # Re: LLVM IR n'est pas portable

    Posté par  . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 3.

    Un exemple tout bête (et valide !) :
    cat ir.c

    int take_ptr(long ptr) {
    return *(int*)ptr;
    }


    clang ir.c -emit-llvm -o - | llvm-as | opt -O3 | llvm-dis

    ; ModuleID = ''
    target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
    target triple = "i386-pc-linux-gnu"
    %struct.__block_descriptor = type { i32, i32 }
    %struct.__block_literal_generic = type { i8*, i32, i32, i8*, %struct.__block_descriptor* }

    define i32 @take_ptr(i32 %ptr) nounwind {
    entry:
    %conv = inttoptr i32 %ptr to i32* ; <i32*> [#uses=1]
    %tmp1 = load i32* %conv ; [#uses=1]
    ret i32 %tmp1
    }


    Note le "long -> i32" qui ne sera pas valide sur une architecture 64 bits. :(
  • # LLVM IR n'est pas portable

    Posté par  . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 2.

    Loin de là.

    Voir la faq llvm : http://llvm.org/docs/FAQ.html => Can I compile C or C++ code to platform-independent LLVM bitcode?

    En pratique, tous les modules ont un "target datalayout" et un "target triple".
    Exemple :
    target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
    target triple = "i386-pc-linux-gnu"
  • # Merci !

    Posté par  . En réponse à la dépêche Publication des vidéos de l'Embedded Linux Conference 2009. Évalué à 10.

    Ça a du demander beaucoup de boulot pour rassembler tout ça !
    En tout cas, c'est sympa de partager avec ceux qui n'étaient pas là.

    Merci. \o/
  • [^] # Re: Interface mal-fagotée?

    Posté par  . En réponse au journal Recette pour se faire du blé, même sans OGM.... Évalué à 9.

    /dev/*, /proc/*, /sys/* et man 2 * ?
  • [^] # Re: C'est juste pour le fun…

    Posté par  . En réponse à la dépêche [Droneries] EMAV 2009. Évalué à 9.

    On est les premiers à râler "parce que non, tu vois le p2p, ça ne sert pas _que_ à pirater".
    Par contre, si on parle de drone, c'est pour nous priver de notre liberté.
    Le travail dans une coutellerie profite aussi bien aux sérials killers qu'aux cuisiniers.

    Le drone, le p2p et le couteau sont des outils. Ils ne sont pas intrinsèquement bons ou mauvais.
  • [^] # Re: Boulot de merde payé une misère qui donne juste le droit à une vi

    Posté par  . En réponse au journal Vélib: agressivité du personnel de maintenance. Évalué à 3.

    C'est provocateur à souhaits.

    Mais il y a un petit fond de vérité qui est là, même si il n'excuse pas tout.
    La politesse, la gentillesse, le savoir-vivre, c'est plus facile quand on est riche et bien portant.
  • [^] # Re: Génial

    Posté par  . En réponse à la dépêche Rencontre de la communauté francophone Elgg. Évalué à 3.

    Un 'moteur de réseau social libre et open-source'. [1]

    [1] http://elgg.elgg.fr/pg/file/fcol/read/2164/slides-de-prsenta(...) (combo inside : flash et/ou powerpoint....)
  • [^] # Re: signals/slots?

    Posté par  . En réponse à la dépêche Qt Software ouvre Qt à la communauté et publie Qt Jambi 4.5. Évalué à 4.

    Le concept ressemble fortement.

    Pour plus d'infos, profite de la superbe doc QT : http://doc.qtsoftware.com/4.5/signalsandslots.html
  • # Northec / fit pc2

    Posté par  . En réponse au journal Faire un mini media center. Évalué à 2.

    Je possède un microclient de hez Northec. [1]

    Je l'utilise en tant que serveur (apache, mail, ftp, ssh...) et j'en suis très content. J'ai aussi essayé de l'utiliser en média center, mais je n'en ai pas été satisfait. (mauvaise qualité des images, du son, pas assez de puissance pour qu'il soit réactif).

    La dernière chose dont j'ai entendu parler, et qui pourrait correspondre, c'est le fit pc2. [2]


    1: http://www.norhtec.com/products/index.html
    2: http://fit-pc2.com/wiki/index.php?title=Main_Page
  • [^] # Re: Jamais content

    Posté par  . En réponse à la dépêche Sortie de la version 4.4 du compilateur GCC. Évalué à 5.

    Le fait que les instructions soient exécutées "out-of-order" ne signifie pas que le résultat de l'opération peut changer.
  • [^] # Re: HTTPS et SSH sur le même port

    Posté par  . En réponse au message [Réseau] démon proxy pour faire rebondir les connexions. Évalué à 1.

    C'est pile poil l'idée. Je vais regarder ça.
    Merci !
  • [^] # Re: socket...

    Posté par  . En réponse au message [Réseau] démon proxy pour faire rebondir les connexions. Évalué à 1.

    Oui tu as raison. C'est une solution.

    Cela dit la création d'un proxy SOCKS est une opération que tu fais sur la machine cliente. Ce n'est donc pas "transparent" pour le client. Par contre, c'est transparent pour le serveur.

    Et justement je cherchais à faire l'inverse, être transparent au niveau du client, et mettre la complexité sur le serveur. :)