Closed n01e0 closed 2 years ago
This is expected because strings can be any suffix. That is, .plt
is a suffix of .rela.plt
. Why do you want to use to_vec
? I don't think it is a useful function.
This is expected because strings can be any suffix. That is, .plt is a suffix of .rela.plt.
Yes, sir. That's right. However, I don't think StrTab::parse takes this into account.
Why do you want to use to_vec? I don't think it is a useful function.
For example, there is no way in current goblin to correctly parse the StrTab
in the section header when you want to do the readelf -S
equivalent as shown here.
So, in #299 , I plan to return the bytes of the StrTab
as a Vec
and provide a way to parse it by myself.
Also, I would like to fix the parsing of Elf.shdr_strtab
in the future, is this a wrong idea?
StrTab::parse
records the offset of the string so that it can be taken into account in get_at
using a binary search.
The equivalent of readelf -S
is to iterate over the section headers, and then use strtab.get_at(section.sh_name)
. There is never a good reason to iterate over individual strings in a StrTab
in my opinion.
Edit: like this
let elf = Elf::parse(&buf)?;
for section in elf.section_headers {
println!("{}", elf.shdr_strtab.get_at(section.sh_name).unwrap());
}
Also, I would like to fix the parsing of Elf.shdr_strtab in the future, is this a wrong idea?
What needs fixing?
Wow I was not aware of this method. This may indeed be sufficient.
It's a small thing, but how about specify in the documentation that "StrTab::to_vec
should not be used for shdr_strtab
"?
It's natural that a user who wants shdr_strtab
in Vec will try to use to_vec
, but it's not easy that he will find that .plt
is not displayed there.
I think an explicit warning would reduce the number of people repeating mistakes like mine in the future.
When I first saw your issue I was puzzled at first too; perhaps a documentation blurb on to_vec
is a good idea? or perhaps showing iteration as a doc comment code example?
How about this?
#[cfg(feature = "alloc")]
/// Converts the string table to a vector of parsed strings.
///
/// Note: If you want to get the correct `Vec` of shdr_strtab, don't use this method but use `get_at` to get it sequentially.
///
/// Requires `feature = "alloc"`
pub fn to_vec(&self) -> error::Result<Vec<&'a str>> {
Yea something like that sounds good to me; or even pasting philipc's code snippet as a ``rust block? (of course the snippet will need some massaging to get working in
cargo test`, so maybe just a simple example with manufactured strtable + symbol addresses as an array that one iterates over?)
anyway, PR's welcome :)
This problem isn't specific to shdr_strtab
; it applies to every strtab. I don't know why to_vec
even exists. As I've said, I don't think it is a useful function. Maybe deprecate it instead.
I don't know why
to_vec
even exists. As I've said, I don't think it is a useful function. Maybe deprecate it instead.
There is no way to access the contents of the parsed string table without to_vec
or something that returns an iterator over the parsed values. Someone might want this, for e.g, displaying what's in the string table without a reference index.
E.g., I use it right here: https://github.com//m4b/bingrep/blob/7a2e2a157ada79afe51b46396347ac706d78a029/src/format_elf.rs#L380
:shrug:
It might be better to remove/deprecate it and just return an impl Iterator<Item = &'a str>
since this wouldn't require the alloc flag
haha, funny enough, in the link i gave, that's actually the to_vec method of Symtab ;) so i guess i don't use it in bingrep, at least, but the point still remains, there's no way to access the parsed strings inside the string table without such a method.
This problem isn't specific to
shdr_strtab
; it applies to every strtab. I don't know whyto_vec
even exists. As I've said, I don't think it is a useful function. Maybe deprecate it instead.
How about creating an appropriate to_vec
method for each StrTab?
For example
impl<'a> Elf<'a> {
pub fn shdr_strtab_to_vec(&self) -> Vec<&str> {
let mut ret = Vec::new();
for shdr in &self.section_headers {
ret.push(self.shdr_strtab.get_at(shdr.sh_name).unwrap_or(""));
}
ret
}
there's no way to access the parsed strings inside the string table without such a method.
Why would you want to do that instead of using get_at
? Ok, maybe for a niche case like bingrep, but most people using this crate aren't writing their own bingrep.
How about creating an appropriate to_vec method for each StrTab?
You very rarely want a list of section header names that are disassociated from the section headers. Typically you only want to process the name in conjunction with other information from the section header. Additionally, nothing says that shdr_strtab
has to be separate from the string table for symbols, and some tools do combine them.
Closing this as I think this is resolved, please re-open if not the case
example
.plt
doesn't appear in shdr_strtab.