[RFA 0/3] Linespec rewrite: Introduction

Keith Seitz keiths@redhat.com
Mon Mar 19 21:19:00 GMT 2012


Hi,

If anyone has been following the archer list, he would know that my 
longtime desire to rewrite linespec.c has finally gotten the best of me.

Basically, I think we all know what a nightmarish experience it is to do 
anything in linespec.c. Its a mess. Fixing bugs and adding new features 
is torturous. The quoting fiasco is out of control. I could go on. Let's 
just say that this is long overdue.

I've explained much of the overall design (w/goals & requirements) in my 
"Stop the insanity!" archer thread 
(http://sourceware.org/ml/archer/2012-q1/msg00011.html). I'm sure that 
those who have been [eagerly?] awaiting the submission of this patch are 
already familiar with this thread, but allow me to briefly explain this 
once more for those who haven't been following along.

Basically, what I've done is split linespec "parsing" into two pieces. 
One is parsing proper. This fills in a "struct linespec". This structure 
could be filled-in by the (new) parser or by some other function (e.g., 
a new MI option which allows "explicit" linespecs).

The second step is turning this structure into all matching SALs (and 
canonicalization of the linespec). That's all there is to it, really.

I apologize ahead of time: the patch for linespec.c (see next patch) is 
*huge*. This is because I have essentially rewritten the whole thing, 
and what I haven't rewritten entirely, I've modified so that we're not 
creating SALs and canonicalizing at every twist and turn.

For those who would prefer to see the patch in action, I encourage you 
to checkout the archer-keiths-linespec-rewrite branch. IMO looking at 
the patch in this context is easier to follow, since the patch is about 
500 lines larger than the actual file.

I've split this patch up into three logical sections:
1) The linespec rewrite itself
2) Other cleanups as fallout of #1 (e.g., removing unused functions) and 
test suite cleanups (different error messages, etc).
3) New tests.

If there is any way reviewers would prefer to see the patches split up, 
let me know and I will attempt to accommodate you.

Keith



More information about the Gdb-patches mailing list