[Toybox] [PATCH] riscv: decode ELF header e_flags.

[enh]

On Mon, Oct 30, 2023 at 3:29 PM Rob Landley <rob at 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 at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net