no_std support

[Zoxc]

It would be nice for gimli to have no_std support so it could be used inside kernels.

[fitzgen]

If we do this, I'd like to put our std use behind a default-on flag, and then use traits to abstract the std vs no_std parts (with one trait implementation for std and then no_std users would supply their own implementations).

[fitzgen]

All of our use std declarations:

$ git grep "use std" src/
src/abbrev.rs:8:use std::collections::hash_map;
src/aranges.rs:6:use std::cmp::Ordering;
src/aranges.rs:7:use std::marker::PhantomData;
src/aranges.rs:8:use std::rc::Rc;
src/aranges.rs:263:    use std::rc::Rc;
src/cfi.rs:8:use std::cell::RefCell;
src/cfi.rs:9:use std::fmt::Debug;
src/cfi.rs:10:use std::marker::PhantomData;
src/cfi.rs:11:use std::mem;
src/cfi.rs:12:use std::str;
src/cfi.rs:2433:    use std::fmt::Debug;
src/cfi.rs:2434:    use std::marker::PhantomData;
src/cfi.rs:2435:    use std::mem;
src/cfi.rs:2436:    use std::u64;
src/constants.rs:28:use std::fmt;
src/endianity.rs:5:use std::fmt::Debug;
src/endianity.rs:6:use std::marker::PhantomData;
src/endianity.rs:7:use std::ops::{Deref, Index, Range, RangeFrom, RangeTo};
src/line.rs:4:use std::ffi;
src/line.rs:5:use std::fmt;
src/line.rs:6:use std::marker::PhantomData;
src/line.rs:1228:    use std::ffi;
src/line.rs:1229:    use std::u8;
src/loc.rs:5:use std::marker::PhantomData;
src/lookup.rs:5:use std::ffi;
src/lookup.rs:6:use std::marker::PhantomData;
src/lookup.rs:7:use std::rc::Rc;
src/op.rs:9:use std::marker::PhantomData;
src/op.rs:14:use std::fmt;
src/op.rs:16:use std::io::Write;
src/parser.rs:3:use std::error;
src/parser.rs:4:use std::ffi;
src/parser.rs:5:use std::fmt::{self, Debug};
src/parser.rs:6:use std::io;
src/parser.rs:7:use std::result;
src/parser.rs:786:    use std::cell::RefCell;
src/pubnames.rs:5:use std::ffi;
src/pubnames.rs:6:use std::marker::PhantomData;
src/pubnames.rs:7:use std::rc::Rc;
src/pubtypes.rs:5:use std::ffi;
src/pubtypes.rs:6:use std::marker::PhantomData;
src/pubtypes.rs:7:use std::rc::Rc;
src/ranges.rs:4:use std::marker::PhantomData;
src/str.rs:3:use std::ffi;
src/str.rs:4:use std::marker::PhantomData;
src/unit.rs:15:use std::cell::Cell;
src/unit.rs:16:use std::ffi;
src/unit.rs:17:use std::marker::PhantomData;
src/unit.rs:18:use std::ops::{Range, RangeFrom, RangeTo};
src/unit.rs:19:use std::{u8, u16};
src/unit.rs:2469:    use std::cell::Cell;
src/unit.rs:2470:    use std::ffi;

[fitzgen]

Most of these have corresponding types in core.

We also use Vec in a few places, but it's in the prelude so doesn't show up here.

When parsing abbreviations, we use std::collections::HashMap to map from abbreviation id to abbreviation shape.

CFI unwinding uses Vec for the evaluation stack and register set. Could pretty easily provide fixed size buffers and pass errors through if we fill it to capacity.

Ditto for line number program evaluation's files and include directories.

[fitzgen]

@Zoxc this is the kind of thing that I'd love to see happen, but is pretty much at the bottom of my personal priorities list. If you want to see this happen, it'll be up to you (no idea if @tromey or @philipc are interested in this effort). That said, I'm happy to help guide you through the code, review PRs, and answer any questions.

Good luck!

[whitequark]

Note: Vec and HashMap are fine on no_std, you just need to use liballoc, for which the requirements are extremely relaxed. The only thing that concerns me is std::io, but this seems pretty rarely used in gimli.

[whitequark]

sfackler/rust-fallible-iterator#3