2015-08-06 13 views
14

Il mio codice sperimentale si arresta in modo anomalo quando è in esecuzione su x86_64-metal (errore di pagina quando IDT non è ancora impostato), ma funziona perfettamente su aarch64.Write :: write_fmt causa un errore di pagina su un metallo nudo

Tramite un'accurata analisi ho scoperto che la causa di questo errore di pagina è costituita da indirizzo danneggiato (molto più alto di 0x200_000, mentre solo la prima pagina 2M è ancora mappata come 1: 1) della funzione "f" passata come argomento al core :: FMT :: ArgumentV1 :: nuovo) funzione (:

#[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 questo valore è codificato dal compilatore rustc essendo risultato dell'elaborazione fase di compilazione format_args! argomenti variadici.

Forse avete suggerimenti su cosa non va in questo caso. Grazie.

+2

Questo suona come un bug di ruggine; prova [aprendo un problema] (https://github.com/rust-lang/rust/issues) su GitHub. – thirtythreeforty

risposta

1

Citato da del RELEASES.md progetto di Rust:

fn tipi di elementi di dimensioni sono pari a zero, e ogni fn nomi un tipo unico. Questo interromperà il codice che trasmette fn s, quindi chiamare transmute su un tipo fn genererà un avviso per alcuni cicli, quindi verrà convertito in errore.

Questo fa parte delle note di rilascio per la versione 1.9.0 (2016/05/26), quindi se si utilizza questa versione potrebbe essere un bug nella libreria std, se siete su < 1.9 probabilmente dovresti provare a copiare il tuo codice nel playpen e lasciare che generi l'assembly in modo da poter vedere da dove proviene effettivamente l'indirizzo.