PpHd (./59) :
Et je suis désolé, mais le linkeur ne devrait pas échouer s'il y a un ordre valide ! Il FAUT tester lorsqu'on réordonne les sections, si le nouvel ordre est valide, ie si toutes les relocs relatives restent possibles avec ce nouvel ordre !
J'avais fait ça dans mon implémentation d'origine. Le problème, c'était que:
* le backtracking pouvait prendre un temps superexponentiel (facteur n_sections! dans le pire des cas). Surtout sur quelque chose d'aussi gros qu'un Flash OS, ça va être totalement inacceptable.
* ça ne marche pas avec l'heuristique plus rapide et plus efficace (programmes plus petits) de Sebastian. Mon heuristique était une heuristique locale qui composait le programme du début à la fin, c'est facile de backtracker dans ce cas, celle de Sebastian repose sur des considérations plus globales. Cela dit, il est possible que cette heuristique marche effectivement mal pour les programmes de plus de 64 KO, elle n'a pas été testée sur un Flash OS parce qu'on n'avait pas de Flash OS en plusieurs sections sur lequel on aurait pu la tester.
Sinon ca ne sert à rien.
Bah si, il suffit de corriger ton code. Les sections sont des unités totalement indépendantes, une section n'a pas le droit de présupposer qu'une autre section va se retrouver immédiatement devant ou derrière.
Et sinon ca ne sert pas à grand chose:
Avec: 121337Sans: 120975
Bah, désactive-le alors et arrête de te plaindre.
Je ne peux pas faire un réarrangeur de sections parfait, la complexité de l'algorithme évident serait en au moins
O(n_sections! * polynom(n_relocs)), c'est totalement intenable, et je ne pense pas qu'il soit possible de le faire en moins de
O(2^n_sections), ce qui est déjà inacceptable (et même là, je ne suis pas sûr que ce soit possible). Si tu sais faire mieux, j'attends ton algorithme.
Et aussi la démonstration de P=NP qui va sans doûte en découler.
Et aussi la démonstration de P=NP qui va sans doûte en découler. 
Et aussi la démonstration de P=NP qui va sans doûte en découler. 
(j/k 