2015-08-06 5 views
14

Mein experimenteller Code stürzt ab, wenn er auf blankem x86_64-metal läuft (Seitenfehler, wenn IDT noch nicht gesetzt ist), funktioniert aber perfekt auf aarch64.Write :: write_fmt verursacht Seitenfehler auf einem Bare-Metal

Durch sorgfältiges Tracing habe ich herausgefunden, dass die Ursache dieses Seitenfehlers aus beschädigter Adresse (viel höher als 0x200_000, während nur die erste 2M Seite noch als 1: 1 gemappt wurde) der Funktion "f" als Argument übergeben wurde zu core :: fmt :: ArgumentV1 :: neu() Funktion:

#[doc(hidden)] 
#[unstable(feature = "fmt_internals", reason = "internal to format_args!")] 
pub fn new<'b, T>(x: &'b T, 
        f: fn(&T, &mut Formatter) -> Result) -> ArgumentV1<'b> { 
    unsafe { 
     ArgumentV1 { 
      formatter: mem::transmute(f), 
      value: mem::transmute(x) 
     } 
    } 
} 

AFAIK ist dieser Wert hartcodiert durch rustc Compiler Ergebnis der Kompilierung-Verarbeitung von format_args zu sein! variadische Argumente.

Vielleicht haben Sie Vorschläge, was mit diesem Fall nicht stimmt. Vielen Dank.

+2

Das klingt wie ein Rost-Käfer; probiere [ein Problem] (https://github.com/rust-lang/rust/issues) auf GitHub. – thirtythreeforty

Antwort

1

aus der RELEASES.md des Rust Zitiert Projekt:

fn Elementtypen sind gleich Null Größe und jeder fn einer einzigartigen Art-Namen. Dies wird Code brechen, der fn s umwandelt, so ruft transmute auf einem fn Typ eine Warnung für ein paar Zyklen, wird dann in einen Fehler umgewandelt werden.

Dies ist Teil der Release Notes für Version 1.9.0 (2016.05.26) so, wenn Sie diese Version verwenden, es könnte ein Fehler in der std Bibliothek sein, wenn Sie auf < 1.9 sind Sie sollten wahrscheinlich versuchen, Ihren Code in die playpen zu kopieren und lassen Sie es die Baugruppe generieren, so dass Sie sehen, wo die Adresse tatsächlich herkommt.