Hi Pedro,

Thanks for the suggestion. Patch updated.

Amos

Pedro Alves <palves@redhat.com> writes:

> On 5/17/19 4:51 PM, Amos Bird wrote:
>> +proc thread_exit {} {
>> +    global decimal
>> +    gdb_test_multiple "call (void)pthread_exit()" "thread 
>> exit" {
>
> Since this is calling a function, it would need to be gated
> with a gdb,cannot_call_functions check (grep for uses).
>
> Does that call return?  If the thread exits, the "call" command 
> will
> continue running without returning to the prompt, right?
>
> I guess that's why you don't expect the prompt here:
>
>> +    gdb_test_multiple "call (void)pthread_exit()" "thread 
>> exit" {
>> +	-re 
>> ".*\032\032thread-exited,id=\"${decimal}\",group-id=\"i${decimal}\"" 
>> {
>> +	    pass "thread exit"
>> +	}
>> +    }
>> +}
>
> Note that this approach means that if someone were to add a test
> after this one, we'd need to either ctrl-c the program, or 
> restart
> gdb.
>
> Please test this with
>
>  make check RUNTESTFLAGS="--target_board=native-gdbserver"
>
> too.  In that case, you're debugging with gdbserver, and 
> gdb/gdbserver
> won't notice that the thread exited until the program next 
> stops.
>
> Also, you probably don't have debug info for glibc/libpthread in 
> your
> system.  I say this because pthread_exit takes an argument and 
> above
> you're not passing any, resulting in undefined behavior.
>
> I'd be much better if the .c file were tweaked to make the 
> thread
> exit on its own, or a new .c file were added for that purpose, 
> IMO.
> E.g., make the main thread join a child thread and hit a 
> breakpoint
> once the thread exits and the join unlocks.
>
>> +	-re 
>> ".*\032\032thread-exited,id=\"${decimal}\",group-id=\"i${decimal}\"" 
>> {
>> +	    pass "thread exit"
>> +	}
>> +    }
>> +}
>> +
>>  thread_test
>>  thread_switch
>> +thread_exit
>>
>>  # restore the original prompt for the rest of the testsuite
>
> Thanks,
> Pedro Alves


--
Amos Bird
amosbird@gmail.com