All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabiano Rosas <farosas@linux.ibm.com>
To: Bruno Piazera Larsen <bruno.larsen@eldorado.org.br>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Lucas Mateus Martins Araujo e Castro
	<lucas.araujo@eldorado.org.br>,
	Luis Fernando Fujita Pires <luis.pires@eldorado.org.br>,
	Fernando Eckhardt Valle <fernando.valle@eldorado.org.br>,
	"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
	Matheus Kowalczuk Ferst <matheus.ferst@eldorado.org.br>,
	"david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>
Subject: RE: [PATCH] target/ppc: code motion from translate_init.c.inc to gdbstub.c
Date: Tue, 13 Apr 2021 10:31:31 -0300	[thread overview]
Message-ID: <871rbe5n0s.fsf@linux.ibm.com> (raw)
In-Reply-To: <CP2PR80MB4499015423A3D0B49610C929C74F9@CP2PR80MB4499.lamprd80.prod.outlook.com>

Bruno Piazera Larsen <bruno.larsen@eldorado.org.br> writes:

> All the code and git related feedback as been done, with the exception of
>
>> > +gchar *ppc_gdb_arch_name(CPUState *cs);
>> > +
>> > +
>> >  #endif /* PPC_CPU_H */
>> > diff --git a/target/ppc/gdbstub.c b/target/ppc/gdbstub.c
>> > index c28319fb97..0c016b8483 100644
>> > --- a/target/ppc/gdbstub.c
>> > +++ b/target/ppc/gdbstub.c
>> > @@ -20,6 +20,10 @@
>> >  #include "qemu/osdep.h"
>> >  #include "cpu.h"
>> >  #include "exec/gdbstub.h"
>> > +#ifdef CONFIG_TCG
>> > +#include "exec/helper-proto.h"
>> > +#endif
>> We still need to figure out where to move the vscr helpers so that both
>> TCG and !TCG code can see them. But we cannot build without TCG
>> currently anyway so I guess it's ok to leave the ifdef.
>
> Actually, since we're moving the helpers away, I think it's better to remove the ifdefs...
> The helper-proto.h is here only for the vscr, so it's going away before we support the !tcg build anyway. Thoughts?

Sure, that's reasonable.

>
>> > +
>> > +void ppc_cpu_gdb_init(CPUState *cs, PowerPCCPUClass *pcc)
>> > +{
>> > +
>> > +    if (pcc->insns_flags & PPC_FLOAT) {
>> > +        gdb_register_coprocessor(cs, gdb_get_float_reg, gdb_set_float_reg,
>> > +                                 33, "power-fpu.xml", 0);
>> > +    }
>> > +    if (pcc->insns_flags & PPC_ALTIVEC) {
>> > +        gdb_register_coprocessor(cs, gdb_get_avr_reg, gdb_set_avr_reg,
>> > +                                 34, "power-altivec.xml", 0);
>> > +    }
>> > +    if (pcc->insns_flags & PPC_SPE) {
>> > +        gdb_register_coprocessor(cs, gdb_get_spe_reg, gdb_set_spe_reg,
>> > +                                 34, "power-spe.xml", 0);
>> > +    }
>> > +    if (pcc->insns_flags2 & PPC2_VSX) {
>> > +        gdb_register_coprocessor(cs, gdb_get_vsx_reg, gdb_set_vsx_reg,
>> > +                                 32, "power-vsx.xml", 0);
>> > +    }
>> > +#ifndef CONFIG_USER_ONLY
>> > +    gdb_register_coprocessor(cs, gdb_get_spr_reg, gdb_set_spr_reg,
>> > +                             pcc->gdb_num_sprs, "power-spr.xml", 0);
>> > +#endif
>> > +}
>>
>> Same here.
>
> This function was actually created by me, wasn't in the translate_init.c.inc. Since we're moving gdb fuinctions to gdbstub.c, I thought it made sense to hide the logic behind how to register coprocessors correctly as well. that's why there is no removal of this function on the diff. Should I move it back to ppc_cpu_realize or is this a good plan?

Right, but you created the function by refactoring the existing code in
translate_init.c.inc so the diff still needs to contain the removal of
the gdb_register_coprocessor calls from that file.

>
>
>
> Bruno Piazera Larsen
>
> Instituto de Pesquisas ELDORADO<http://clickemailmkt.eldorado.org.br/ls/click?upn=UPoxpeIcHnAcbUZyo7TTaswyiVb1TXP3jEbQqiiJKKGsxOn8hBEs5ZsMLQfXkKuKXZ7MVDg0ij9eG8HV4TXI75dBzDiNGLxQ8Xx5PzCVNt6TpGrzBbU-2Biu0o69X5ce-2FW-2FOk1uUipuK0fZnWXJEgbRw-3D-3DJY4T_wWk-2BG6VvNBoa1YzxYjhCdFS9IfANIaBzDSklR1NyyrKOI1wj0P-2BdBFcuO4FnHcsA1MyHu0ly1Yt3oDMp7KKdJPM68iKuI2jiRH5v4B0d8wf3chU3qy5n5iXWnW1QjSaNFHOgELzxaP-2FnesTeBgJ5dFkjH4f279sVQpOtyjw5xAqj34M6pgNRAxVvuXif4IWDcVzXg1FzfYlEfkKzr9vvpA3Hg8kitwMtlU3zwbQUBCgL30fQoJPcRPMGKyOY8RmoAlXNqTJYDYIvqmfnI7KLUvw6vKB5R-2B5q1FJRAzX7H-2BmF0NnDET6jMLuIqtCcVIch>
>
> Departamento Computação Embarcada
>
> Analista de Software Trainee
>
> Aviso Legal - Disclaimer<https://www.eldorado.org.br/disclaimer.html>


      reply	other threads:[~2021-04-13 13:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12 19:04 [PATCH] target/ppc: code motion from translate_init.c.inc to gdbstub.c Bruno Larsen (billionai)
2021-04-12 21:00 ` Fabiano Rosas
2021-04-13 12:48   ` Bruno Piazera Larsen
2021-04-13 13:31     ` Fabiano Rosas [this message]

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=871rbe5n0s.fsf@linux.ibm.com \
    --to=farosas@linux.ibm.com \
    --cc=bruno.larsen@eldorado.org.br \
    --cc=david@gibson.dropbear.id.au \
    --cc=fernando.valle@eldorado.org.br \
    --cc=lucas.araujo@eldorado.org.br \
    --cc=luis.pires@eldorado.org.br \
    --cc=matheus.ferst@eldorado.org.br \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.