Re: [PATCH 8/8] Tests for validate symbol file using build-id.

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 16 Apr 2013 17:15:04 +0200, Aleksandar Ristovski wrote:
> On 13-04-14 10:18 AM, Jan Kratochvil wrote:
> >On Tue, 09 Apr 2013 17:27:45 +0200, Aleksandar Ristovski wrote:
> >>+  set nocrlf "\[^\r\n\]*"
> >>+  set expected_header "From${nocrlf}To${nocrlf}Syms${nocrlf}Read${nocrlf}Shared${nocrlf}"
> >>+  set expected_line "${symsloaded}${nocrlf}${solibfile}"
> >>+
> >>+  gdb_test "info sharedlibrary ${solibfile}" \
> >>+    "${expected_header}\r\n.*${expected_line}.*" \
> >>+    "${msg} - Symbols for ${solibfile} loaded: expected '${symsloaded}'"
> >
> >Those .* around ${expected_line} destroy the whole purpose of ${nocrlf} as
> >they can match anything.  To make it really single-line one can use for
> >example:
> 
> I was aiming at matching ${symsloaded} and ${solibfile} on
> _the_same_ line, but ignore if there are extra lines. I believe this
> guards against e.g.
> 
> ............. Yes ....... SomeOtherLibraryNotSureWhyMatchedTheRegexp
> ............. No ......... ${solibfile}
> 
> In this case, if 'Yes' is expected, it would not match.

That was the purpose, it would FAIL as such case is unexpected and user should
investigate/bugreport why it happened.  (It would be absolutely correct to
rather report UNRESOLVED rather than FILE in the unexpected multi-line case.)

But if it was intentional how you wrote it I do not mind either way.


> >   set footer_line {\(\*\): Shared library is missing debugging information\.}
> >+
> >     "${expected_header}\r\n${nocrlf}${expected_line}${nocrlf}(?:\r\n$footer_line)?" \
> >
> >
> >>+  return 0
> >
> >The return value (0) is not used by any caller.  And also just "return" at and
> >of proc is redundant, remove it.
> 
> Actually, I was going to use it to communicate failures within the
> function - changed accordingly. If something goes wrong in one run
> of solib_matching_test, it will print UNTESTED and continue, I
> believe this would aid diagnostics of the issues.

OK, I found now the caller has been updated.


Thanks,
Jan