From: Aleksandar Ristovski <aristovski@qnx.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [patch] validate binary before use
Date: Tue, 02 Apr 2013 18:02:00 -0000 [thread overview]
Message-ID: <515B12D1.7050505@qnx.com> (raw)
In-Reply-To: <20130402165306.GA9479@host2.jankratochvil.net>
On 13-04-02 12:53 PM, Jan Kratochvil wrote:
> Hi Aleksandar,
>
> just some obvious issues of the testsuite first:
>
>
> On Tue, 02 Apr 2013 18:24:18 +0200, Aleksandar Ristovski wrote:
>>>> + send_gdb "set verbose 1\n"
>>>
>>> Never (only in some exceptional cases) use send_gdb, it creates races wrt
>>> syncing on end of the commands. Use gdb_test or gdb_test_no_output.
>>
>> [AR] I very much dislike using gdb_test unless I actually am doing a
>> test. Otherwise, we end up with testcases that tend to have 30-40
>> passes but only 2-3 relevant. Thus, when these 2-3 relevant ones
>> start to FAIL it is easy to neglect that due to false cozy feeling
>> that, well, *most* are still passing.
>
> * Even a single PASS->FAIL can be a serious GDB regression.
> * There are still many racy testcases (with "random" results).
> * Therefore comparing any PASS/FAIL counts is irrelevant, only diff matters.
>
> Besides that send_gdb really does not work, it does not read the "(gdb) "
> response will confuse the later first test which does wait for a response.
[AR]
Ok, it's been a while since I looked at gdb.exp closely, and
'no-message' was added since. Changed the test as so:
@@ -93,15 +93,7 @@ proc solib_matching_test { solibfile symsloaded msg } {
set bp_location [gdb_get_line_number "set breakpoint 1 here"]
- send_gdb "tbreak ${srcfile}:${bp_location}\n"
- gdb_expect {
- -re "Temporary breakpoint.*${gdb_prompt} $" {
- }
- default {
- untested "${msg} - Failed to set temp. breakpoint at ${bp_location}"
- return -1
- }
- }
+ gdb_breakpoint ${srcfile}:${bp_location} temporary no-message
gdb_run_cmd { ${binlibfiledirrun} }
gdb_expect {
>
> If you do not like trivial testcase names then just use:
> gdb_test_no_output "command" ""
> or
> gdb_test "command" "response" ""
> GDB testsuite handles testcase name "" by omitting it from the output.
>
>
>>>> + send_gdb "tbreak ${srcfile}:${bp_location}\n"
>>>
>>> Do not use send_gdb and there is gdb_breakpoint function.
>>
>> [AR] I am not testing setting breakpoints. I do not want these to
>> show up as PASS-es. These passes are irrelevant. The assumption is
>> that breakpoints do work; there are other tests for breakponts.
>
> gdb_breakpoint does not produce any PASS message when it succeeds.
> But it will FAIL if a problem occured.
>
>
>>>> + send_gdb "run\r\n"
>>>
>>> Use runto_main. And check its result code.
>>
>> [AR] The same. I am not testing run to main. I am testing this
>> particular feature. There are other tests that test runto_main.
>
> Again, successful runto_main does not produce any PASS message.
[AR]
It does produce PASS (see gdb.exp, lines 476-488), but this comment is
not relevant as test does not use 'run' any more, it uses gdb_run_cmd;
it does not need to stop at main, just run to the line it wants.
>
>
>>>> + gdb_test "info sharedlibrary ${solibfile}" \
>>>> + ".*From.*To.*Syms.*Read.*Shared.*\r\n.*${symsloaded}.*" \
>>> ^^
>>> BTW leading .* is excessive, gdb_test regex does not have anchored its start.
>>
>> [AR] ok.
>>
>>>
>>>
>>>> + "Symbols for ${solibfile} loaded: expected '${symsloaded}'"
>>>
>>> Protect ${symsloaded} by [string_to_regexp $string] as user
>>> may have regex-unsafe characters there.
>>
>> [AR] symsloaded is argument passed to solib_matching_test, and the
>> test is the only user. Ther eare no other users, and the string may
>> contain only 'Yes' or 'No'.
>
> OK, I did not notice, I agree string_to_regexp is not needed there.
>
> But when you expect only one shared library make the expectation explicit,
> both for a single line and for ${binlibfilebase}.
>
> gdb_test "info sharedlibrary ${solibfile}" \
> "From\[^\r\n\]*To\[^\r\n\]*Syms\[^\r\n\]*Read\[^\r\n\]*Shared\[^\r\n\]*\r\n\[^\r\n\]*${symsloaded}\[^\r\n\]*[string_to_regexp ${binlibfilebase}]" \
> (I did not test this regex.)
>
> I can very well imagine GDB could print >= 2 lines or a line without
> ${binlibfilebase} there which could make false PASS.
[AR] How can it print >= 2 lines? I will augument regex to explicitly
look for ${solibfile}
@@ -124,7 +124,7 @@ proc solib_matching_test { solibfile symsloaded msg } {
}
gdb_test "info sharedlibrary ${solibfile}" \
- "From.*To.*Syms.*Read.*Shared.*\r\n.*${symsloaded}.*" \
+ "From.*To.*Syms.*Read.*Shared.*\r\n.*${symsloaded}.*${solibfile}.*" \
"${msg} - Symbols for ${solibfile} loaded: expected '${symsloaded}'"
return 0
}
Thanks,
Aleksandar
next prev parent reply other threads:[~2013-04-02 17:18 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 20:21 Aleksandar Ristovski
2012-12-24 19:57 ` Aleksandar Ristovski
2012-12-25 7:37 ` Jan Kratochvil
2012-12-27 20:07 ` Aleksandar Ristovski
2012-12-27 20:59 ` Jan Kratochvil
2012-12-27 21:03 ` Aleksandar Ristovski
2012-12-27 21:13 ` Jan Kratochvil
2012-12-27 21:21 ` Aleksandar Ristovski
2013-01-29 16:15 ` Aleksandar Ristovski
2013-01-30 19:17 ` Jan Kratochvil
2013-01-31 14:23 ` Aleksandar Ristovski
2013-02-01 3:06 ` Jan Kratochvil
2013-02-01 14:31 ` Aleksandar Ristovski
2013-02-01 20:43 ` Jan Kratochvil
2013-02-01 21:32 ` Aleksandar Ristovski
2013-02-02 12:25 ` Jan Kratochvil
2013-02-21 21:00 ` Aleksandar Ristovski
2013-02-21 21:07 ` Jan Kratochvil
2013-01-31 6:35 ` Jan Kratochvil
2013-01-31 14:24 ` Aleksandar Ristovski
2013-02-22 15:09 ` Aleksandar Ristovski
2013-02-27 17:42 ` Aleksandar Ristovski
2013-02-27 18:14 ` Aleksandar Ristovski
2013-03-22 16:58 ` Aleksandar Ristovski
2013-03-22 14:45 ` Aleksandar Ristovski
2013-03-28 20:56 ` Jan Kratochvil
2013-04-02 17:25 ` Aleksandar Ristovski
2013-04-02 17:32 ` Aleksandar Ristovski
2013-04-02 17:45 ` Jan Kratochvil
2013-04-02 18:02 ` Aleksandar Ristovski [this message]
2013-04-03 18:52 ` Jan Kratochvil
2013-04-04 11:07 ` Aleksandar Ristovski
2013-04-04 13:30 ` Jan Kratochvil
2013-04-04 17:15 ` Aleksandar Ristovski
2013-04-04 18:11 ` Aleksandar Ristovski
2013-04-05 13:03 ` Jan Kratochvil
2013-04-05 16:08 ` Aleksandar Ristovski
2013-04-07 6:06 ` Jan Kratochvil
2013-04-08 18:54 ` Pedro Alves
2013-04-09 1:15 ` Jan Kratochvil
2013-04-05 15:05 ` Aleksandar Ristovski
2013-04-07 10:24 ` Aleksandar Ristovski
2013-04-08 18:32 ` Jan Kratochvil
2013-04-07 5:54 ` Jan Kratochvil
2013-04-04 3:16 ` Jan Kratochvil
2012-12-26 19:24 ` Poenitz Andre
2012-12-27 20:10 ` Aleksandar Ristovski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=515B12D1.7050505@qnx.com \
--to=aristovski@qnx.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox