This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RISC-V support

On Tue, Jan 08, 2019 at 02:52:33PM +0100, Mark Wielaard wrote:
> > There is a problem here though.  The riscv support was written to try
> > to handle both 32-bit and 64-bit targets with a single elfutils
> > backend.  But I have 6 ABIs I need to (theoretically) handle in
> > riscv_retval.c.  The return_value_location function doesn't take any
> > ebl or elf pointer, so I can't handle it there.  I can handle it in
> > riscv_init.c by checking ebl and elf pointers there, and calling an
> > appropriate function, but I'm not sure if that is OK.  Currently,
> > none
> > of the *_init.c files are using the elf pointer argument.
> The ppc64 init does (to lookup the odp table which is necessary for
> ppc64[be], but not ppc64le). It is allowed. And the backends/ebl
> interface is completely internal, so feel free to suggest changes if
> they make sense for riscv. If it is necessary we'll just update the
> other backends.

I've been looking at mips, and it seems to have many different
ABIs too. A patch I've received does this:
mips_return_value_location (Dwarf_Die *functypedie, const Dwarf_Op **locp)
  /* First find the ABI used by the elf object */
  enum mips_abi abi = find_mips_abi(functypedie->cu->dbg->elf);

The patch only supports 6 ABIs, but I think there are really over
10 ABIs.

Maybe it would be good that we only need to determine the ABI
once, instead of each time the function is called.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]