From: Mark Wielaard <mark@klomp.org>
To: Ying Huang <ying.huang@oss.cipunited.com>
Cc: elfutils-devel@sourceware.org
Subject: Re: [PATCH v3 6/6] backends: Add register_info, return_value_location, core_note function on mips
Date: Fri, 5 Apr 2024 12:42:39 +0200 [thread overview]
Message-ID: <20240405104239.GF1292@gnu.wildebeest.org> (raw)
In-Reply-To: <20240305095122.889077-7-ying.huang@oss.cipunited.com>
Hi,
On Tue, Mar 05, 2024 at 05:51:22PM +0800, Ying Huang wrote:
> From: Ying Huang <ying.huang@oss.cipunited.com>
>
> Signed-off-by: Ying Huang <ying.huang@oss.cipunited.com>
> ---
> backends/Makefile.am | 3 +-
> backends/mips_corenote.c | 85 +++++++++++++++++
> backends/mips_init.c | 3 +
> backends/mips_regs.c | 135 +++++++++++++++++++++++++++
> backends/mips_retval.c | 196 +++++++++++++++++++++++++++++++++++++++
> 5 files changed, 421 insertions(+), 1 deletion(-)
> create mode 100644 backends/mips_corenote.c
> create mode 100644 backends/mips_regs.c
> create mode 100644 backends/mips_retval.c
Similar to the previous one. Added a ChangeLog entry to the commit
message:
* backends/Makefile.am (mips_SRCS): Add mips_regs.c,
mips_retval.c and mips_corenote.c.
* backends/mips_init.c (mips_init): HOOK register_info,
return_value_location and core_note.
* backends/mips_corenote.c: New file.
* backends/mips_regs.c: Likewise.
* backends/mips_retval.c: Likewise.
The implementations of core_note, register_info and
return_value_location do look plausible. Pushed.
Although there is one small issue/question:
> diff --git a/backends/mips_corenote.c b/backends/mips_corenote.c
> new file mode 100644
> index 00000000..aeadeb17
> --- /dev/null
> +++ b/backends/mips_corenote.c
> @@ -0,0 +1,85 @@
> +/* MIPS specific core note handling.
> + Copyright (C) 2024 CIP United Inc.
> + This file is part of elfutils.
> [...]
> +#ifdef HAVE_CONFIG_H
> +# include <config.h>
> +#endif
> +
> +#include <elf.h>
> +#include <inttypes.h>
> +#include <stddef.h>
> +#include <stdio.h>
> +#include <sys/time.h>
> +
> +#define BACKEND mips_
> +#include "libebl_CPU.h"
> +
> +#define BITS 64
> +#ifndef BITS
> +# define BITS 32
> +#else
> +# define BITS 64
> +#endif
So this only handles 64 BITS. I left it this way. But it is a
question about the whole series. MIPS has multiple abis, some 32, some
64 bits, some big and some little endian. If I understand correctly
this backend only handles the 64 bit little endian one?
Again it would be nice if you could come up with non-native variants
of the tests so the implementation can also be tested on non-MIPS
arches. Specifically for tests/run-allregs.sh, tests/run-funcretval.sh
and/or tests/run-readelf-mixed-corenote.sh.
Thanks,
Mark
next prev parent reply other threads:[~2024-04-05 10:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-05 9:51 Ying Huang
2024-04-05 10:42 ` Mark Wielaard [this message]
2024-04-18 9:30 ` Ying Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240405104239.GF1292@gnu.wildebeest.org \
--to=mark@klomp.org \
--cc=elfutils-devel@sourceware.org \
--cc=ying.huang@oss.cipunited.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).