gdb: test to check one aspect of the linespec parsing code

While working on the fix for PR cli/28665 (see previous couple of
commits), I was playing with making a change in the linespec parsing
code.  Specifically, I was thinking about whether the spec_string for
LINESPEC_LOCATION locations should ever be nullptr.

I made a change to prevent the spec_string from ever being nullptr,
tested gdb, and saw no regressions.

However, as part of this work I was reviewing how the breakpoint code
handles this case (spec_string being nullptr), and spotted that in
parse_breakpoint_sals the nullptr case is specifically handled, so
changing this should have caused a regression.  But I didn't see one.

So, this commit adds a comment in location.c mentioning that the
nullptr case is (a) not an oversight, and (b) is required.  Then I add
a new test to gdb.base/break.exp that ensures a change in this area
will cause a regression.

This test passes on current gdb, but with my modified (and broken)
gdb, the test would fail.

1 files changed, 5 insertions, 0 deletions

diff --git a/gdb/location.c b/gdb/location.c
index 299ef7e..0459980 100644
--- a/gdb/location.c
+++ b/gdb/location.c
@@ -134,6 +134,11 @@ struct event_location_linespec : public event_location
 
 	linespec_lex_to_end (linespec);
 	p = remove_trailing_whitespace (orig, *linespec);
+
+	/* If there is no valid linespec then this will leave the
+	   spec_string as nullptr.  This behaviour is relied on in the
+	   breakpoint setting code, where spec_string being nullptr means
+	   to use the default breakpoint location.  */
 	if ((p - orig) > 0)
 	  linespec_location.spec_string = savestring (orig, p - orig);
       }