On Mon, Oct 30, 2023 at 3:29 PM Rob Landley <r...@landley.net> wrote: > > On 10/29/23 13:05, enh via Toybox wrote: > > --- > > lib/lib.c | 13 +++++++++++++ > > lib/lib.h | 1 + > > toys/other/readelf.c | 3 ++- > > toys/posix/file.c | 5 +++-- > > 4 files changed, 19 insertions(+), 3 deletions(-) > > I have a bad cold and am too unfocused to trust myself poking at the code to > much right now, but adding a riscv specific elf flag printing function to > lib.c > and lib.h seems a bit... ew? That's not even a generic ELF function, that's > "flags for one architecture that can't figure out what it's ABI is" elf > function.
heh, i almost included some arm32 flags (that i personally don't care about) just to make it look less like this is riscv-specific :-) but you're right --- they shouldn't have done it this way. funnily enough, they realized that a little later, so there's a separate attribute that does it "less badly" given the huge mess that is risc-v's "anything is possible!" ABI nightmare. you'll be seeing a readelf patch for that too eventually, but [right now at least] "is it using C?" and "what's the float ABI?" are fairly useful questions in their own right. even though i don't think "which revision of the arm32 eabi is this exactly?" is useful, i think there's a reasonable argument that arm32 soft-float vs hard-float is still sadly relevant in 2023 (citation needed? https://wiki.debian.org/ArmPorts), and that's in the header flags. i can send you that as a follow-up patch if you like. i just don't remember any Android app developer making that mistake before! > Tempted to glue readelf.c and file.c together into the same source file so > they > can share this function that way, but lemme try to get enough soup and cold > medicine to think clearly and maybe come up with a better solution... i guess my thinking is the opposite --- the main reason i haven't sent you an nm.c yet is that it too wants the "iterate over the things in an elf file, calling this callback" stuff moved out into lib/, so i've been seeing that as inevitable but low-priority. (hence calling this function elf_print_flags() rather than print_elf_flags() --- i'm assuming there will be more elf_* functions in lib eventually.) > Rob > _______________________________________________ > Toybox mailing list > Toybox@lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
