Oui, mais les méthodes sont des fonctions, donc vues par "nm"... On peut d'ailleurs les caster en tant que tel avec le type IMP (pointeur de fonction) :
Pas du tout ! Une méthode est une méthode. Si certaines méthodes Objective-C possèdent une entrée dans la table de symbole de ton fichier Mach-O, c'est parce que gcc à fait une optimisation en transformant la méthode en fonction. Toutefois, si tu utilises les capacités objets et les capacités avancées de l'Objective-C sur les classes, alors gcc ne pourra plus transformer tes méthodes en "fonctions", et leur nom ne sera plus présents dans la table de symbole, mais uniquement dans la section "__module_info" qui contient, entre autres, la structure de classe, des propriétés, et des héritages.
Alors il faudra m'expliquer comment fonctionne la méthode "+ (IMP)instanceMethodForSelector:(SEL)aSelector" de NSObject
IMP étant défini comme "typedef id (*IMP)(id, SEL, ...);" (pointeur de fonction C)
Non mais t'as dit qu'une méthode Objective-C n'était pas une fonction C, et pourtant c'est le cas, elles ne sont peut-être pas référencées au niveau des bibliothèques mais il s'agit bel et bien de fonctions C qui possèdent deux arguments cachés de type id et SEL et qui sont appelés grâce aux fonctions objc_msgSend...().
Et quand j'ai dit que le runtime Objective-C avait changé, et que ça pouvait bloqué la lecture des fichiers Mach-O, je pensais surtout aux structures qui ont été modifiées et son devenues des types opaques et qui donc pouvaient avoir été modifiées en-dessous...
Non mais t'as dit qu'une méthode Objective-C n'était pas une fonction C
Oui c'est ce que je dit.
dans 1201443951:
pourtant c'est le cas, elles ne sont peut-être pas référencées au niveau des bibliothèques mais il s'agit bel et bien de fonctions C qui possèdent deux arguments cachés de type id et SEL et qui sont appelés grâce aux fonctions objc_msgSend...().
Oui tu peut les représenter comme des fonctions C, ça je ne te contredit pas. Que objc_msgSend() arrive sur le code en question en mémoire, je ne te contredit pas. Toutefois à aucun moment une méthode Objective-C n'est une fonction C ni un symbole standard (sauf cas d'optimisation, je le redit, c'est à dire quand objc_msgSend() n'est pas utilisé)... Mais par compilation, construction ça n'est pas la même chose. Et par définition ça n'est pas une fonction (tout cours) : c'est une méthode.
dans 1201443951:
Et quand j'ai dit que le runtime Objective-C avait changé, et que ça pouvait bloqué la lecture des fichiers Mach-O, je pensais surtout aux structures qui ont été modifiées et son devenues des types opaques et qui donc pouvaient avoir été modifiées en-dessous...
Oui pour la section "__module_info", mais ça n'est pas le cas. Et même la plupart du temps on ne fait pas de modification à ce niveau là .
Bah alors je me pose des quesitons... Parce que je suis en train de créer un framework et de la même manière qu'avec Appkit ou Foundation, toutes les méthodes que je définis sont affichées avec nm...
Oui, j'en avais fait un à une époque. J'essaye de le refaire, dès que j'y arrive je le donne.
[EDIT] Bon du mal à trouver. Je continus de chercher le code que j'avais fait pour démontrer ça.
Mais de toute façon il faut garder en tête que même si gcc met les symboles des méthodes dans la table de symbole, ça n'en fait pas des fonctions pour autant. Je ne baisse pas les bras pour les méthodes dans la table de symbole, j'avais testé ! Grmm.
GCC leur donne un nom tout pourris pour permettre leur différenciation par rapport aux autres fonctions, mais ce sont bien des fonctions ! Des méthodes que GCC convertis en fonctions en leur ajoutant deux paramètres...
GCC leur donne un nom tout pourris pour permettre leur différenciation par rapport aux autres fonctions, mais ce sont bien des fonctions !
On ne peut pas parler de fonction ni de méthode au sein du code machine généré par GCC. Il y a des routines, oui. Mais je persiste à dire qu'on ne parle ni de fonction, ni de fonction C dans ce cas (même si on a la possibilité d'appeller la routine représentant le contenus de la méthode via un pointeur sur fonction). ça n'est qu'une vue bas niveau de la chose, et ça n'est pas correcte d'un point de vue terminologique.
Pour ce qui est des symboles des méthode dans la table de symbole, forcément je me suis discrédité vu que je n'apporte pas de preuve, mais vraiment je suis sûr de moi. Je le retrouverais ce code !
Réponses
Alors il faudra m'expliquer comment fonctionne la méthode "+ (IMP)instanceMethodForSelector:(SEL)aSelector" de NSObject
IMP étant défini comme "typedef id (*IMP)(id, SEL, ...);" (pointeur de fonction C)
Je n'ai pas dit qu'on ne pouvais pas avoir un pointeur de fonction C sur une méthode Objective-C.
En fait, j'ai mal quoté ton message : je voulais m'arrêter au "nm"
Et quand j'ai dit que le runtime Objective-C avait changé, et que ça pouvait bloqué la lecture des fichiers Mach-O, je pensais surtout aux structures qui ont été modifiées et son devenues des types opaques et qui donc pouvaient avoir été modifiées en-dessous...
Oui c'est ce que je dit.
Oui tu peut les représenter comme des fonctions C, ça je ne te contredit pas. Que objc_msgSend() arrive sur le code en question en mémoire, je ne te contredit pas. Toutefois à aucun moment une méthode Objective-C n'est une fonction C ni un symbole standard (sauf cas d'optimisation, je le redit, c'est à dire quand objc_msgSend() n'est pas utilisé)...
Mais par compilation, construction ça n'est pas la même chose. Et par définition ça n'est pas une fonction (tout cours) : c'est une méthode.
Oui pour la section "__module_info", mais ça n'est pas le cas. Et même la plupart du temps on ne fait pas de modification à ce niveau là .
Tout est là à priori...
ça doit être qu'Apple n'utilise pas suffisamment les capacités objets et les capacités avancées de l'Objective-C :fouf):
Non non, c'est juste qu'ils n'utilisent pas grand chose qui ne peut pas être compilé de manière statique.
Oui, j'en avais fait un à une époque. J'essaye de le refaire, dès que j'y arrive je le donne.
[EDIT] Bon du mal à trouver. Je continus de chercher le code que j'avais fait pour démontrer ça.
Mais de toute façon il faut garder en tête que même si gcc met les symboles des méthodes dans la table de symbole, ça n'en fait pas des fonctions pour autant.
Je ne baisse pas les bras pour les méthodes dans la table de symbole, j'avais testé ! Grmm.
Des méthodes que GCC convertis en fonctions en leur ajoutant deux paramètres...
On ne peut pas parler de fonction ni de méthode au sein du code machine généré par GCC. Il y a des routines, oui. Mais je persiste à dire qu'on ne parle ni de fonction, ni de fonction C dans ce cas (même si on a la possibilité d'appeller la routine représentant le contenus de la méthode via un pointeur sur fonction). ça n'est qu'une vue bas niveau de la chose, et ça n'est pas correcte d'un point de vue terminologique.
Pour ce qui est des symboles des méthode dans la table de symbole, forcément je me suis discrédité vu que je n'apporte pas de preuve, mais vraiment je suis sûr de moi. Je le retrouverais ce code !