This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] symbol hashing, part 2/n - ALL_BLOCK_SYMBOLS
Daniel Jacobowitz writes:
> On Thu, Oct 11, 2001 at 08:42:41PM -0400, Andrew Cagney wrote:
> > As you said, it is a double-edged sword. The other edge has a very
> > unusual feature. Identify simple mechanical self contained changes and
> > often go in as obvious. The review cycle goes down and can often be
> > reduced to zero.
>
> The problem is that I'm working entirely on intrusive changes in code
> owned by other people. There are no parts I'm willing to commit as
> obvious, and every time I break them up further I introduce
> intermediate stages that I have to adequately test.
Yes, true. In the printcmd.c file case though I would think that if
you did a test run with both changes in, the splitting would be ok.
>
> > My reading of Elena's comment:
> >
> > >Yes, I looked ths over and it seems to work, except that I would really
> > >prefer the change to printcmd.c split in two. The first bit to
> > >rationalize that "if (func)..." code. This would have with it all
> > >the indentation changes as well. The code as it is now doesn't really
> > >make much sense. So, that looks a good change to me. But it has nothing
> > >to do with the new macro. After that change is in, you can introduce
> > >the macro in printcmd.c w/o having all the indent changes.
> > >It also makes it easier to distinguish a no-op change (the macro) from
> > >the other one.
> >
> > is that you're all approved.
>
> Well, I need to repost the patch anyway after Elena's comments, so I'll
> wait on assuming that.
>
Just repost the extra conversions to use the macro that we identified.
> > Your first commit fixes some messed up logic. It is a cleanup (but
> > pretty obvious). It doesn't have anything to do with the (ULGH) macro.
> > By keeping it separate it makes it possible to better isolate the
> > breakage it could cause when we have to go back (in 6 months) to find a
> > bug ;-)
> >
> > Your second commit is this new (ULGH) macro. The macro (ULGH) shouldn't
> > break anything but it is however still a (ULGH) macro. Just include the
> > extra tweeks you found.
> >
> > (If you haven't figured it out, breakpoint.h has a similar (ULGH) macro
> > so I'm biteing my tongue on this change :-)
>
> Heh. I wonder what Andrew thinks of macros?
>
> Seriously, there's nothing to be done without adding the complexity of
> iterators. I want these structures to be treated opaquely, damn it.
> For now, macros it is.
>
Yes, no problem.
Elena
> --
> Daniel Jacobowitz Carnegie Mellon University
> MontaVista Software Debian GNU/Linux Developer