Support `.a` and `.rlib` static library files

[nyurik]

Is your feature request related to a problem? Please describe.

The .a static library is essentially an ar archive of elf files. I think the file reader could simply merge multiple elf files together when displaying, or some "context" or "stream" concept could be introduced to some screens, allowing switching between individual elf files in a single archive.

To try it out locally, use ar x <file> to extract all .o files, which already can be viewed with binsider

Describe the solution you'd like

Ability to view .a files

Describe alternatives you've considered

using nm and objdump to view file content

[orhun]

Hey, thanks for creating the issue 👋🏼

Interesting feature request! Would you mind giving me more information about when this would be useful in real world scenario? I'm not that familiar with analyzing .a files (or with .a files for that matter).

To try it out locally, use ar x to extract all .o files, which already can be viewed with binsider

I'm not sure if I understood this correctly, but where would you usually get an .a file? Just wanted to try it out for myself :)

[nyurik]

any compilation right before linking into an executable produces a bunch of .a files. A rust compilation produces .rlib files - which are almost identical to .a (they have some extra metadata i heard). So to try it out, simply look at your target/ dir, e.g. target/debug/libbinsider.rlib - and run ar x target/debug/libbinsider.rlib and do cargo run <one of the extracted files.o>

[orhun]

Thanks for the detailed explanation, I just got the chance to try this out and yeah, I think it would be nice to be able to run e.g. binsider .* in the directory full of ELF files and support a file menu inside the TUI for selecting individual files. Is that also what you had in mind?

[nyurik]

This one is tricky... My initial usecase was to inspect the exported symbols. Given a .a or .rlib file, I don't really need to know which object inside has the needed symbol - to me, it is all one big file, but I am sure someone may want to know more in-depth info.

So perhaps these changes?

Introduce component list

Just like you suggested, you may want to have another screen when your input is an archive. That screen would list all archive components, and might offer some search capabilities that would look for things in all components. Once you hit enter, you will see the current UI that displays info for just one component.

I do not think you should support multiple files at the same time. There are enough tools for file management, e.g. yazi, and I'm not sure you want to duplicate that functionality. I see you currently allow more than one [FILE]..., but when i tried to give multiple binaries, it simply showed the info about the last one, so not sure why you have that.

Maybe eventually you may want to add capability to search for symbols or strings or some other filtering capabilities - in which case yes, you might want to show a directory, listing only the binaries, and having some metadata next to each (as a table) - like some info from the file headers, string count, etc.

Flatten Static screen sub-pages

The Static screen has a bunch of sub-pages like headers, symbols, .... I didn't even realize you can go through them because the mouse clicks were ignored, and the left/right arrows were not in the help string. That said, I think you may want to move all of them to the top menu to keep things simpler, and because these lists are pretty big to be viewed in part of a screen.