This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] ppc: include register numbers in gdbarch_tdep structure.
On Dec 10, 3:47pm, Elena Zannoni wrote:
> Subject: Re: [RFA] ppc: include register numbers in gdbarch_tdep structure
> > > #define PPC_MQ_REGNUM gdbarch_tdep (current_gdbarch)->ppc_mq_regnum
> >
> > As with most things we do there are pros and cons. On the pro side, I
> > agree that it looks prettier and is easier to read. Also, having
> > these defines makes it easier to convert the code back to using actual
> > constants some day. These are both excellent reasons to do as Michael
> > suggests.
>
> Why would you want to convert the code back?
Andrew recently said the following:
On paper, it should be possible to describe the entire raw regcache
using constants. I'm finding that, in reality, until all the relevant
framework is fleshed out (eg my regcache breakage, everything
multi-arch) it isn't really possible. Sigh.
This suggests to me that someday, though probably not very soon, it
may indeed be possible to use actual constants. As you can probably
tell, I really, really hate the overhead of a function call to provide
the value of something that ought to be a constant.
> Anyway, I find it also
> easier to debug the code, if you don't have a macro.
So do I. Perhaps someday GDB will have support for macros.
> > The drawback to using a macro like this is that it hides what's really
> > going on. (But note that it is this very same quality that enhances
> > readability.) In this case, the macro looks like a constant, leading
> > to the expectation that it is a constant and has the usual costs
> > associated with constants. However, the runtime costs associated with
> > using this expression are significantly greater than using a constant.
> >
>
> But having a macro defined to be the same function call is not going
> to speed up the evaluation.
I wasn't claiming that it would. I was providing an argument against
the use of a macro. My argument is that the macro hides (in the sense
that you have to go look at the macro's definition) the fact that a
function is being called. I wasn't claiming that the macro eliminated
the function call.
> > That said, those of us accustomed to working on GDB are used to this
> > by now, aren't we? E.g, consider:
> >
> > for (regno = 0; regno < NUM_REGS; regno++)
> > ...
> >
> > We all realize that a function is being called each time the test
> > ``regno < NUM_REGS'' is performed, don't we?
>
> Sometimes, doing something because it was done in the past is not a
> good metric. I think multiarch was developed leaving the macros
> because it was a necessary thing to both minimize changes and keep
> compatibility with non-multiarched targets. But here I would argue it
> is a different situation.
I agree. But I wasn't citing NUM_REGS as a historical precedent.
Rather, I was noting that since we're all used to macros performing
function calls for us, that my argument against the use of the macro
wasn't a very strong one.
> > If so, then I'm all in favor of Michael's suggestion. (Actually, I'm
> > in favor of Michael's suggestion anyway. But, I do think we need to
> > be more careful about how we write code that might potentially contain
> > a hidden function call.)
>
> Sorry, I disagree.
That's okay. I don't plan to do anything about this one way or another
until there's been more discussion.
Kevin