Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: scanish am 11. November 2009, 20:41
-
Hi,
ja eigentlich wollte ich an was anderem Arbeiten, aber nachdem ich mein Ubuntu geupdatet hab, weigerte sich GRUB plötzlich, meinen Kernel zu laden. Nach einem kurzen Blick auf die Datei erklärte sich die Weigerung: Die Datei war ohne zusätzlichen Code oder irgendwelche Änderungen von 12 KB auf 1.0012 MB gewachsen. Weil der ld nach dem Update die 1 MB Grenze in die Datei eingefügt hatte (der typ ist .elf). Ich hab es mir im Hexcode angesehen, das erstem Megabyte ist mit 0x00 gefüllt.
Ich hab nicht mal was am linkerscript geändert. Ich werd das hier mal posten:
OUTPUT_FORMAT(elf32-i386)
OUTPUT_ARCH(i386)
ENTRY(start)
phys = 0x100000;
SECTIONS
{
.text phys : AT(phys)
{
code = .;
*(.text)
*(.rodata)
start_ctors = .; *(.ctors) end_ctors = .;
start_dtors = .; *(.dtors) end_dtors = .;
. = ALIGN(0x1000);
}
.data : AT(phys + (data - code))
{
data = .;
*(.data)
}
.bss : AT(phys + (bss - code))
{
bss = .;
*(COMMON)
*(.bss)
. = ALIGN(0x1000);
}
end = .;
}
Ist die selbe, die ich immer nehme. Hab ich vielleicht eine gravierende Änderung verpasst? Ich hab nichtmal bemerkt, dass es so einen großen Versionssprung beim ld gab...
Ich hoffe ihr könnt mir helfen, weil mich das nervt, dass ich sonst nicht weiterarbeiten kann =/
-
Versuch mal, dem ld --nmagic als Parameter mitzugeben.
-
Jetzt geht's. :?
Vielen Dank.
-
Soweit ich das verstehe, veranlasst --nmagic den Linker dazu, das Pagealigning abzuschalten.
-
Ich hab wegen dem Problem mal recherchiert, weil es das gleiche Problem ist warum man Grub legacy nicht mehr mit dem Ubuntu 9.10 bauen kann.
Der Übeltäter ist wohl das neue Feature build-id (https://fedoraproject.org/wiki/Releases/FeatureBuildId) in Binutils 2.20. Eigentlich soll es nur eine ID in das Binary schreiben, damit man z.B. core dumps genau zuordnen kann, aber es scheint dafür das Binary erstmal auf "echte" Größe zu bringen. Mit --build-id=none kann man das deaktiveren, vielleicht steckt das in --nmagic irgendwie drin.
-
Hm, brauche ich die Option dann auch in meinem Beispielkernel? Kannst du das mal kurz mit tutorial.git ausprobieren, wenn du ein betroffenes System da hast?
Ansonsten wäre es vielleicht nicht schlecht, wenn du in den GRUB-Artikel einen Absatz zum Bauen einbauen könntest. Ich nehme an, das Problem wird in Zukunft öfter auftreten.
-
Ich krieg den Fehler auf den Tutorial Kernel nicht reproduziert. Selbst wenn ich das Linkerscript von scanish benutze. Es scheint also noch etwas anderes nötig zu sein damit der Fehler auftritt.
Zum Thema Grub hab ich noch keine ordentliche Lösung gefunden. Das Problem ist, dass Grub schon beim configure Schritt prüft ob die Binutils richtig arbeiten und ich keinerlei Ahnung von autoconf habe.
-
LDFLAGS="--build-id=none" ./configureIrgendwie sowas vielleicht?
-
Das haut irgendwie nicht hin. In den Tests übernimmt der gcc implizit das linken und er der macht aus dem --build-id -fbuild-id und beschwert sich das der Parameter unbekannt ist.
Dann hab ich mir den autoconf Kram angeguckt, überall den Parameter eingetragen aber das configure script läuft immer noch nicht durch.
So langsam glaube ich da ist noch ein anderes Problem. Dieses build-id soll wohl doch schon in vorherigen Binutils versionen vorhanden gewesen sein.
-
Dann würde ich
LDFLAGS="-Xlinker --build-id=none" ./configureprobieren, wenn der gcc selbst --build-id nicht kennt.
-
Mit "CFLAGS="-fno-stack-protector -Wl,--build-id=none" ./configure" hab ich es jetzt geschafft Grub zu bauen, aber es bootet nicht. Stage1 sieht zwar in ordnung aus und hat die Bootsignatur, aber nach dem installieren über die grub shell fehlt die Bootsignatur.
Edit: Es klappt doch, also die CFLAGS sind die Lösung.
-
Na ja ich hab den GRUB ja nicht gebaut, das ist noch eine uralt-version. Seit Ewigkeiten benutz ich die weil sie ja immer funktioniert hat. Gebaut hab ich die noch auf Ubuntu 8.04, glaub ich.
Aber es klappt ja und das kernelende wird offenbar auch ordentlich aligned mit --nmagic.