Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding a higher level API on top of DIE parsing/traversal #82

Open
fitzgen opened this issue Aug 29, 2016 · 4 comments
Open

Consider adding a higher level API on top of DIE parsing/traversal #82

fitzgen opened this issue Aug 29, 2016 · 4 comments

Comments

@fitzgen
Copy link
Member

fitzgen commented Aug 29, 2016

Something like this:

struct Subprogram {
    ...
}

impl Subprogram {
    pub fn new(die: DebuggingInformationEntry) -> Subprogram {
        assert!(die.tag() == DW_TAG_subprogram);
        Subprogram { ... }
    }

    pub fn name(&self) -> Option<&ffi::CStr> { ... }

    pub fn linkage_name(&self) -> Option<&ffi::CStr> { ... }

    pub fn calling_convention(&self) -> Option<DwCc> { ... }

    pub fn is_pure(&self) -> Option<bool> { ... }

    pub fn is_recursive(&self) -> Option<bool> { ... }

    // Etc...
}

Would ideally be able to become owned, if the user wants to copy the data.

@grissiom
Copy link

When I writing a program that parse global variable addresses( https://github.com/grissiom/elfvars/ ), I found I have to pass the gimli::Abbreviations and gimli::DebugStr all the way down if I want to do "lazy parsing"(travel only portion of the DIE and than parse only the DIEs that relevant).

IMHO, the abbreviations and debug_str associated with a CU does not change in the middle. So a higher level API may group those info into a struct and make the methods easier to use.

@philipc
Copy link
Collaborator

philipc commented Feb 19, 2017

It's not just those two that you need. DIEs can contain references to most other sections too, and so you currently need to pass those sections down too if you want to use those values (the dwarfdump example passes down abbrev/line/loc/ranges/str). Definitely open to ideas for making this easier to use though.

@fitzgen
Copy link
Member Author

fitzgen commented Feb 19, 2017

If we had an Image for the whole object file, it might help solve the issues here as well as potentially making #182 more ergonomic. The down side would be that gimli has to get a deeper understanding of object files, rather than having it be completely another crate's concern.

@grissiom
Copy link

Maybe we could handover the "parsing" of the ELF to other crates such as object or xmas-elf. But only store the section data references in the Image.

For #182 , I think we could let Reader to do the ELF parsing for us and we just need to &[uint8] read(".debug_info", offset). If the backend of Reader is memmap, than we could get Zero-copy for free. If the backend is internet, it could do some COW.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants