Salut,

En fait je viens de passer mon aprem sur un soucis bizarre.

Après un update par recompilation des sources de mon laptop vers 7.1-RELEASE-p3, le boot loader crashait. Une investigation et surtout le "Fixit" du CD d'install, m'ont permis de comprendre que le problème venait de /boot/loader.

Une recherche m'a permis de découvrir que certains avait eu des problème avec loader mais en 7-STABLE, lorsque les CFLAGS n'étaient pas standard.

Et voilà après avoir recompilé loader (cd /usr/src/sys/boot && make) et réinstaller le stage 2 dans le label du disque (bsdlabel -B <partition DOS>), le loader crashe avec mes CFLAGS non standard alors qu'il fonctionne bien avec les CFLAGS standards.

Le pire c'est que mais CFLAGS sont tout simples: -O2 -pipe -funroll-loops

Est-ce que quelqu'un à déjà au le soucis ?

CFLAGS certe tout simple, mais CFLAGS de ricer quand même, -funroll-loops est connu pour être une source énorme de bugs. Vire le et tu verras que tout de suite ça ira mieux. En plus vue le peux que ça apporte c'est carrément négligeable un CFLAGS comme celui là.

Si tu veux de l'optimisation, un simple CPU_TYPE+=native dans ton make.conf est largement suffisant, les ports qui peuvent bénéficier d'une optimisation des CFLAGS de le propose sous l'option OPTIMIZED_CFLAGS genre mplayer, etc.

Merci du conseil. Je l'ai viré, par contre, c'est la première fois que je vois des plaintes contre le -funroll-loops. Mais bon visiblement, mon aventure montre que je peux te faire confiance  :)

Donc je reste avec un CPU_TYPE adapté à mon cpu, ça ira bien.

boot2 est fortement contraint question taille (je suis pas certain mais je crois que c'est du 8Ko dans le cas des disklabels 32bits, 32Ko quand c'est du disklabel64, sur DFly): il y a eu une discussion dans dragonfly-kernel sur ces questions assez récemment.
Le «déroulage» des boucles pourrait bien faire dépasser ces limites au code produit (limites dues au mode de fonctionnement du processeur au moment où boot1 charge boot2).

fgudin wrote on 24. Mar 2009 at 09:19:

boot2 est fortement contraint question taille (je suis pas certain mais je crois que c'est du 8Ko dans le cas des disklabels 32bits, 32Ko quand c'est du disklabel64, sur DFly): il y a eu une discussion dans dragonfly-kernel sur ces questions assez récemment. Le «déroulage» des boucles pourrait bien faire dépasser ces limites au code produit (limites dues au mode de fonctionnement du processeur au moment où boot1 charge boot2).

C'est un problème récurrent sur les listes freeBSD aussi.

Effectivement, le déroulage des boucles augmente bien la taille de loader de façon significative:

Avec: 323584 octets
Sans: 294912 octets

soit +28ko environ

Par contre, boot, boot1 et boot2 restent de la même taille.