* [PATCH] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp
@ 2021-11-23 3:39 Tiezhu Yang
2021-11-23 8:25 ` Tom de Vries
0 siblings, 1 reply; 6+ messages in thread
From: Tiezhu Yang @ 2021-11-23 3:39 UTC (permalink / raw)
To: gdb-patches
If /proc/sys/kernel/yama/ptrace_scope is 1, when execute attach-pie-noexec.exp
without superuser, the gdb.log shows the following info:
(gdb) attach 6500
Attaching to process 6500
ptrace: Operation not permitted.
(gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
It is obviously wrong, the expected result should be FAIL in such a case.
With this patch:
(gdb) attach 6600
Attaching to process 6600
ptrace: Operation not permitted.
(gdb) FAIL: gdb.base/attach-pie-noexec.exp: attach (please check privileges and try again)
When check this log info if failed, we can do the following processes to test:
(1) set ptrace_scope as 0
$ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
$ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
(2) use sudo to test
$ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
gdb/testsuite/gdb.base/attach-pie-noexec.exp | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/gdb/testsuite/gdb.base/attach-pie-noexec.exp b/gdb/testsuite/gdb.base/attach-pie-noexec.exp
index 85161fa..c029003 100644
--- a/gdb/testsuite/gdb.base/attach-pie-noexec.exp
+++ b/gdb/testsuite/gdb.base/attach-pie-noexec.exp
@@ -59,7 +59,15 @@ set testpid [spawn_id_get_pid $test_spawn_id]
gdb_start
file delete -- $binfile
-gdb_test "attach $testpid" "Attaching to process $testpid\r\n.*" "attach"
+set test "attach"
+gdb_test_multiple "attach $testpid" $test {
+ -re "Attaching to process $testpid\r\n.*No executable file now.*\r\n$gdb_prompt $" {
+ pass $test
+ }
+ -re "Attaching to process $testpid\r\n.*ptrace: Operation not permitted\\.\r\n$gdb_prompt $" {
+ fail "$test (please check privileges and try again)"
+ }
+}
gdb_test "set architecture $arch" "The target architecture is set to \"$arch\"\\."
gdb_test "info shared" "From\[ \t\]+To\[ \t\]+Syms Read\[ \t\]+Shared Object Library\r\n0x.*"
--
2.1.0
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp
2021-11-23 3:39 [PATCH] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp Tiezhu Yang
@ 2021-11-23 8:25 ` Tom de Vries
2021-11-23 10:16 ` Tiezhu Yang
0 siblings, 1 reply; 6+ messages in thread
From: Tom de Vries @ 2021-11-23 8:25 UTC (permalink / raw)
To: Tiezhu Yang, gdb-patches
On 11/23/21 4:39 AM, Tiezhu Yang wrote:
> If /proc/sys/kernel/yama/ptrace_scope is 1, when execute attach-pie-noexec.exp
> without superuser, the gdb.log shows the following info:
>
> (gdb) attach 6500
> Attaching to process 6500
> ptrace: Operation not permitted.
> (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
>
> It is obviously wrong, the expected result should be FAIL in such a case.
>
Agreed, PASS is incorrect, I suppose though that UNTESTED or UNSUPPORTED
would be better than FAIL.
Anyway, looking earlier in the test-case I see:
...
if {![can_spawn_for_attach]} {
return 0
}
...
and in gdb/testsuite/lib/gdb.exp I see:
...
# Return true if we can spawn a program on the target and attach to
# it.
proc can_spawn_for_attach { } {
...
So, is it not a more complete fix to make can_spawn_for_attach to return
false for this case? It would have to setup a small test-case, compile
it to exec, spawn it and try to attach to it. This is much more work
than it's currently doing, so it would have to become a
gdb_caching_proc. For an example, look for instance at
target_supports_scheduler_locking .
Thanks,
- Tom
> With this patch:
>
> (gdb) attach 6600
> Attaching to process 6600
> ptrace: Operation not permitted.
> (gdb) FAIL: gdb.base/attach-pie-noexec.exp: attach (please check privileges and try again)
> > When check this log info if failed, we can do the following processes
to test:
> (1) set ptrace_scope as 0
> $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
> $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
> (2) use sudo to test
> $ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
>
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> ---
> gdb/testsuite/gdb.base/attach-pie-noexec.exp | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/gdb.base/attach-pie-noexec.exp b/gdb/testsuite/gdb.base/attach-pie-noexec.exp
> index 85161fa..c029003 100644
> --- a/gdb/testsuite/gdb.base/attach-pie-noexec.exp
> +++ b/gdb/testsuite/gdb.base/attach-pie-noexec.exp
> @@ -59,7 +59,15 @@ set testpid [spawn_id_get_pid $test_spawn_id]
>
> gdb_start
> file delete -- $binfile
> -gdb_test "attach $testpid" "Attaching to process $testpid\r\n.*" "attach"
> +set test "attach"
> +gdb_test_multiple "attach $testpid" $test {
> + -re "Attaching to process $testpid\r\n.*No executable file now.*\r\n$gdb_prompt $" {
> + pass $test
> + }
> + -re "Attaching to process $testpid\r\n.*ptrace: Operation not permitted\\.\r\n$gdb_prompt $" {
> + fail "$test (please check privileges and try again)"
> + }
> +}
> gdb_test "set architecture $arch" "The target architecture is set to \"$arch\"\\."
> gdb_test "info shared" "From\[ \t\]+To\[ \t\]+Syms Read\[ \t\]+Shared Object Library\r\n0x.*"
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp
2021-11-23 8:25 ` Tom de Vries
@ 2021-11-23 10:16 ` Tiezhu Yang
2022-01-05 6:35 ` Tiezhu Yang
0 siblings, 1 reply; 6+ messages in thread
From: Tiezhu Yang @ 2021-11-23 10:16 UTC (permalink / raw)
To: Tom de Vries, gdb-patches
On 11/23/2021 04:25 PM, Tom de Vries wrote:
> On 11/23/21 4:39 AM, Tiezhu Yang wrote:
>> If /proc/sys/kernel/yama/ptrace_scope is 1, when execute attach-pie-noexec.exp
>> without superuser, the gdb.log shows the following info:
>>
>> (gdb) attach 6500
>> Attaching to process 6500
>> ptrace: Operation not permitted.
>> (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
>>
>> It is obviously wrong, the expected result should be FAIL in such a case.
>>
>
> Agreed, PASS is incorrect, I suppose though that UNTESTED or UNSUPPORTED
> would be better than FAIL.
>
> Anyway, looking earlier in the test-case I see:
> ...
> if {![can_spawn_for_attach]} {
> return 0
> }
> ...
> and in gdb/testsuite/lib/gdb.exp I see:
> ...
> # Return true if we can spawn a program on the target and attach to
>
> # it.
>
>
> proc can_spawn_for_attach { } {
> ...
>
> So, is it not a more complete fix to make can_spawn_for_attach to return
> false for this case? It would have to setup a small test-case, compile
> it to exec, spawn it and try to attach to it. This is much more work
> than it's currently doing, so it would have to become a
> gdb_caching_proc. For an example, look for instance at
> target_supports_scheduler_locking .
Hi Tom,
Thanks for your reply and suggestion.
Let me use UNSUPPORTED if "ptrace: Operation not permitted." at this
moment, I will send v2 soon.
Thanks,
Tiezhu
>
> Thanks,
> - Tom
>
>> With this patch:
>>
>> (gdb) attach 6600
>> Attaching to process 6600
>> ptrace: Operation not permitted.
>> (gdb) FAIL: gdb.base/attach-pie-noexec.exp: attach (please check privileges and try again)
>>> When check this log info if failed, we can do the following processes
> to test:
>> (1) set ptrace_scope as 0
>> $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
>> $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
>> (2) use sudo to test
>> $ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
>>
>> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
>> ---
>> gdb/testsuite/gdb.base/attach-pie-noexec.exp | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/gdb/testsuite/gdb.base/attach-pie-noexec.exp b/gdb/testsuite/gdb.base/attach-pie-noexec.exp
>> index 85161fa..c029003 100644
>> --- a/gdb/testsuite/gdb.base/attach-pie-noexec.exp
>> +++ b/gdb/testsuite/gdb.base/attach-pie-noexec.exp
>> @@ -59,7 +59,15 @@ set testpid [spawn_id_get_pid $test_spawn_id]
>>
>> gdb_start
>> file delete -- $binfile
>> -gdb_test "attach $testpid" "Attaching to process $testpid\r\n.*" "attach"
>> +set test "attach"
>> +gdb_test_multiple "attach $testpid" $test {
>> + -re "Attaching to process $testpid\r\n.*No executable file now.*\r\n$gdb_prompt $" {
>> + pass $test
>> + }
>> + -re "Attaching to process $testpid\r\n.*ptrace: Operation not permitted\\.\r\n$gdb_prompt $" {
>> + fail "$test (please check privileges and try again)"
>> + }
>> +}
>> gdb_test "set architecture $arch" "The target architecture is set to \"$arch\"\\."
>> gdb_test "info shared" "From\[ \t\]+To\[ \t\]+Syms Read\[ \t\]+Shared Object Library\r\n0x.*"
>>
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp
2021-11-23 10:16 ` Tiezhu Yang
@ 2022-01-05 6:35 ` Tiezhu Yang
2022-01-05 13:10 ` Tom de Vries
0 siblings, 1 reply; 6+ messages in thread
From: Tiezhu Yang @ 2022-01-05 6:35 UTC (permalink / raw)
To: Tom de Vries, gdb-patches
On 11/23/21 18:16, Tiezhu Yang wrote:
> On 11/23/2021 04:25 PM, Tom de Vries wrote:
>> On 11/23/21 4:39 AM, Tiezhu Yang wrote:
>>> If /proc/sys/kernel/yama/ptrace_scope is 1, when execute
>>> attach-pie-noexec.exp
>>> without superuser, the gdb.log shows the following info:
>>>
>>> (gdb) attach 6500
>>> Attaching to process 6500
>>> ptrace: Operation not permitted.
>>> (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
>>>
>>> It is obviously wrong, the expected result should be FAIL in such a
>>> case.
>>>
>>
>> Agreed, PASS is incorrect, I suppose though that UNTESTED or UNSUPPORTED
>> would be better than FAIL.
>>
>> Anyway, looking earlier in the test-case I see:
>> ...
>> if {![can_spawn_for_attach]} {
>> return 0
>> }
>> ...
>> and in gdb/testsuite/lib/gdb.exp I see:
>> ...
>> # Return true if we can spawn a program on the target and attach to
>>
>> # it.
>>
>>
>> proc can_spawn_for_attach { } {
>> ...
>>
>> So, is it not a more complete fix to make can_spawn_for_attach to return
>> false for this case? It would have to setup a small test-case, compile
>> it to exec, spawn it and try to attach to it. This is much more work
>> than it's currently doing, so it would have to become a
>> gdb_caching_proc. For an example, look for instance at
>> target_supports_scheduler_locking .
>
> Hi Tom,
>
> Thanks for your reply and suggestion.
>
> Let me use UNSUPPORTED if "ptrace: Operation not permitted." at this
> moment, I will send v2 soon.
>
> Thanks,
> Tiezhu
>
Hi,
I sent the following v2 patch in November 2021, any more comments for
this version?
[PATCH v2] gdb: testsuite: fix wrong expected result in
attach-pie-noexec.exp
https://sourceware.org/pipermail/gdb-patches/2021-November/183699.html
Thanks,
Tiezhu
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp
2022-01-05 6:35 ` Tiezhu Yang
@ 2022-01-05 13:10 ` Tom de Vries
2022-01-06 13:21 ` Tiezhu Yang
0 siblings, 1 reply; 6+ messages in thread
From: Tom de Vries @ 2022-01-05 13:10 UTC (permalink / raw)
To: Tiezhu Yang, gdb-patches
On 1/5/22 07:35, Tiezhu Yang wrote:
> On 11/23/21 18:16, Tiezhu Yang wrote:
>> On 11/23/2021 04:25 PM, Tom de Vries wrote:
>>> On 11/23/21 4:39 AM, Tiezhu Yang wrote:
>>>> If /proc/sys/kernel/yama/ptrace_scope is 1, when execute
>>>> attach-pie-noexec.exp
>>>> without superuser, the gdb.log shows the following info:
>>>>
>>>> (gdb) attach 6500
>>>> Attaching to process 6500
>>>> ptrace: Operation not permitted.
>>>> (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
>>>>
>>>> It is obviously wrong, the expected result should be FAIL in such a
>>>> case.
>>>>
>>>
>>> Agreed, PASS is incorrect, I suppose though that UNTESTED or UNSUPPORTED
>>> would be better than FAIL.
>>>
>>> Anyway, looking earlier in the test-case I see:
>>> ...
>>> if {![can_spawn_for_attach]} {
>>> return 0
>>> }
>>> ...
>>> and in gdb/testsuite/lib/gdb.exp I see:
>>> ...
>>> # Return true if we can spawn a program on the target and attach to
>>>
>>> # it.
>>>
>>>
>>> proc can_spawn_for_attach { } {
>>> ...
>>>
>>> So, is it not a more complete fix to make can_spawn_for_attach to return
>>> false for this case? It would have to setup a small test-case, compile
>>> it to exec, spawn it and try to attach to it. This is much more work
>>> than it's currently doing, so it would have to become a
>>> gdb_caching_proc. For an example, look for instance at
>>> target_supports_scheduler_locking .
>>
>> Hi Tom,
>>
>> Thanks for your reply and suggestion.
>>
>> Let me use UNSUPPORTED if "ptrace: Operation not permitted." at this
>> moment, I will send v2 soon.
>>
>> Thanks,
>> Tiezhu
>>
>
> Hi,
>
> I sent the following v2 patch in November 2021, any more comments for
> this version?
>
> [PATCH v2] gdb: testsuite: fix wrong expected result in
> attach-pie-noexec.exp
> https://sourceware.org/pipermail/gdb-patches/2021-November/183699.html
Did you try the can_spawn_for_attach approach I suggested?
Thanks,
- Tom
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp
2022-01-05 13:10 ` Tom de Vries
@ 2022-01-06 13:21 ` Tiezhu Yang
0 siblings, 0 replies; 6+ messages in thread
From: Tiezhu Yang @ 2022-01-06 13:21 UTC (permalink / raw)
To: Tom de Vries, gdb-patches
On 1/5/22 21:10, Tom de Vries wrote:
> On 1/5/22 07:35, Tiezhu Yang wrote:
>> On 11/23/21 18:16, Tiezhu Yang wrote:
>>> On 11/23/2021 04:25 PM, Tom de Vries wrote:
>>>> On 11/23/21 4:39 AM, Tiezhu Yang wrote:
>>>>> If /proc/sys/kernel/yama/ptrace_scope is 1, when execute
>>>>> attach-pie-noexec.exp
>>>>> without superuser, the gdb.log shows the following info:
>>>>>
>>>>> (gdb) attach 6500
>>>>> Attaching to process 6500
>>>>> ptrace: Operation not permitted.
>>>>> (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach
>>>>>
>>>>> It is obviously wrong, the expected result should be FAIL in such a
>>>>> case.
>>>>>
>>>>
>>>> Agreed, PASS is incorrect, I suppose though that UNTESTED or
>>>> UNSUPPORTED
>>>> would be better than FAIL.
>>>>
>>>> Anyway, looking earlier in the test-case I see:
>>>> ...
>>>> if {![can_spawn_for_attach]} {
>>>> return 0
>>>> }
>>>> ...
>>>> and in gdb/testsuite/lib/gdb.exp I see:
>>>> ...
>>>> # Return true if we can spawn a program on the target and attach to
>>>>
>>>> # it.
>>>>
>>>>
>>>> proc can_spawn_for_attach { } {
>>>> ...
>>>>
>>>> So, is it not a more complete fix to make can_spawn_for_attach to
>>>> return
>>>> false for this case? It would have to setup a small test-case, compile
>>>> it to exec, spawn it and try to attach to it. This is much more work
>>>> than it's currently doing, so it would have to become a
>>>> gdb_caching_proc. For an example, look for instance at
>>>> target_supports_scheduler_locking .
>>>
>>> Hi Tom,
>>>
>>> Thanks for your reply and suggestion.
>>>
>>> Let me use UNSUPPORTED if "ptrace: Operation not permitted." at this
>>> moment, I will send v2 soon.
>>>
>>> Thanks,
>>> Tiezhu
>>>
>>
>> Hi,
>>
>> I sent the following v2 patch in November 2021, any more comments for
>> this version?
>>
>> [PATCH v2] gdb: testsuite: fix wrong expected result in
>> attach-pie-noexec.exp
>> https://sourceware.org/pipermail/gdb-patches/2021-November/183699.html
>
> Did you try the can_spawn_for_attach approach I suggested?
Yes, I did the following changes of gdb/testsuite/lib/gdb.exp.
If you are OK, I will send it as a normal v3 patch later.
Thanks,
Tiezhu
>8------------------------------------------------------8<
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 97bedd5cb5..12b37270c8 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -5030,7 +5030,10 @@ proc gdb_exit { } {
# Return true if we can spawn a program on the target and attach to
# it.
-proc can_spawn_for_attach { } {
+gdb_caching_proc can_spawn_for_attach {
+ global gdb_prompt
+ set test "can spawn for attach"
+
# We use exp_pid to get the inferior's pid, assuming that gives
# back the pid of the program. On remote boards, that would give
# us instead the PID of e.g., the ssh client, etc.
@@ -5045,6 +5048,32 @@ proc can_spawn_for_attach { } {
return 0
}
+ set me "can_spawn_for_attach"
+ set src { int main() { sleep (600); return 0; } }
+ if {![gdb_simple_compile $me $src executable]} {
+ return 0
+ }
+
+ set test_spawn_id [spawn_wait_for_attach $obj]
+ set test_pid [spawn_id_get_pid $test_spawn_id]
+
+ gdb_start
+ file delete $obj
+ gdb_test_multiple "attach $test_pid" $test {
+ -re "Attaching to process $test_pid\r\n.*No executable file
now.*\r\n$gdb_prompt $" {
+ pass $test
+ kill_wait_spawned_process $test_spawn_id
+ return 1
+ }
+ -re "Attaching to process $test_pid\r\n.*ptrace: Operation not
permitted\\.\r\n$gdb_prompt $" {
+ unsupported "$test (please check privileges and try again)"
+ kill_wait_spawned_process $test_spawn_id
+ return 0
+ }
+ }
+
+ kill_wait_spawned_process $test_spawn_id
+
# Assume yes.
return 1
}
@@ -5094,12 +5123,6 @@ proc spawn_id_get_pid { spawn_id } {
proc spawn_wait_for_attach { executable_list } {
set spawn_id_list {}
- if ![can_spawn_for_attach] {
- # The caller should have checked can_spawn_for_attach itself
- # before getting here.
- error "can't spawn for attach with this target/board"
- }
-
foreach {executable} $executable_list {
# Note we use Expect's spawn, not Tcl's exec, because with
# spawn we control when to wait for/reap the process. That
>
> Thanks,
> - Tom
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-06 13:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-23 3:39 [PATCH] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp Tiezhu Yang
2021-11-23 8:25 ` Tom de Vries
2021-11-23 10:16 ` Tiezhu Yang
2022-01-05 6:35 ` Tiezhu Yang
2022-01-05 13:10 ` Tom de Vries
2022-01-06 13:21 ` Tiezhu Yang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).