From: Pedro Alves <palves@redhat.com>
To: Andreas Tobler <andreast-list@fgznet.ch>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] patch to refactor ppc64 specific code from ppc-linux-tdep
Date: Mon, 21 Jan 2013 15:50:00 -0000 [thread overview]
Message-ID: <50FD6398.3000807@redhat.com> (raw)
In-Reply-To: <50DCBF4B.7000009@fgznet.ch>
Hi Andreas,
On 12/27/2012 09:36 PM, Andreas Tobler wrote:
> in order to avoid code duplication for the FreeBSD powerpc port I
> started to cut off common code from ppc-linux-tdep.c into a new file to
> be used for FreeBSD and GNU/Linux PowerPC 64-bit. The file name is open
> so far. Better namings are welcome.
Thanks for doing this.
IMO, the "common" monitor is practically meaningless, and raises the question
of what's different between ppc64-common-tdep.c, and
an hypothetical ppc64-tdep.c, and/or the rs6000-tdep.c, as the
second would be about common ppc64 bits, and the latter, extant, _is also_
about common ppc bits. IOW, if we need a new ppc function in the future that's
be used by several OSs, how do we decide where it goes? "common" doesn't
give any clue. So I'd suggest ppc64-linbsd-tdep.c, and/or
rs6000-tdep.c/ppc64-tdep.c, for shared code that is not OS specific (yeah,
rs6000-tdep.c is a misnomer nowadays).
>
> Attached my first attempt, tested on GNU/Linux ppc64, Fedora 17 and on
> x86_64-*freebsd* with --eanble-targets=all. On the Linux side I do not
> see any regression.
> So far I have only covered functions which I can use on FreeBSD
> powerpc64. There might be others too but I do not see any for now.
>
> I'd appreciate comments, corrections.
>
> TIA,
> Andreas
>
> 2012-12-19 Andreas Tobler <andreast@neon.andreas.nets>
>
> * Makefile.in (ALL_TARGET_OBS): Add new file ppc64-common-tdep.o
Missing period.
> (HFILES_NO_SRCDIR): Likewise.
> (ALLDEPFILES): Likewise.
> * configure.tgt: Add new file for powerpc-linux.
> * ppc64-common-tdep.h: New file.
> * ppc64-common-tdep.c New file.
> (insn_d, insn_ds, insn_xfx, read_insn)
> (insns_match_pattern, insn_d_field, insn_ds_field)
> (ppc64_desc_entry_point): Move from ppc-linux-tdep.c to here.
> (PPC64_STANDARD_LINKAGE1_LEN, PPC64_STANDARD_LINKAGE2_LEN)
> (PPC64_STANDARD_LINKAGE2_LEN): Likewise and use ARRAY_SIZE macro.
> (ppc64_standard_linkage1_target, ppc64_standard_linkage2_target)
> (ppc64_standard_linkage3_target, ppc64_skip_trampoline_code): Move
> from ppc-linux-tdep.c to here.
> (ppc64_convert_from_func_ptr_addr): Rename it from
> ppc64_linux_convert_from_func_ptr_addr to
> ppc64_convert_from_func_ptr_addr and move it from ppc-linux-tdep.c to
> here.
> * ppc-linux-tdep.c: Include ppc64-common-tdep.h.
> Removed above functions.
> (ppc_linux_init_abi): Rename
> ppc64_linux_convert_from_func_ptr_addr to
> ppc64_linux_convert_from_func_ptr_addr.
> +/* An instruction to match. */
> +
> +struct insn_pattern
...
> +
> +int
> +insns_match_pattern (CORE_ADDR pc, struct insn_pattern *pattern,
> + unsigned int *insn);
> +CORE_ADDR
> +insn_d_field (unsigned int insn);
These look like basic architecture/instruction pattern matching.
I suggest moving to ppc-tdep.h/rs6000-tdep.c instead.
If we're making these extern, then it'd be good to add a "ppc_" or
"ppc64_" prefix (could be a separate step).
Also, GDB's convention is that the function name goes on the first
column in function definitions only, not declarations, and that
declarations in .h files get an explicit "extern".
Otherwise looks fine to me.
--
Pedro Alves
next prev parent reply other threads:[~2013-01-21 15:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-27 21:36 Andreas Tobler
2013-01-19 13:46 ` Andreas Tobler
2013-01-21 15:50 ` Pedro Alves [this message]
2013-01-26 16:24 ` Andreas Tobler
2013-02-01 19:00 ` Pedro Alves
2013-02-01 20:55 ` Andreas Tobler
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=50FD6398.3000807@redhat.com \
--to=palves@redhat.com \
--cc=andreast-list@fgznet.ch \
--cc=gdb-patches@sourceware.org \
/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