Re: [bug?] [patch] target remote and multiprocess+

[Matthias Pfaller <leo at marco dot de>]

On 11/21/2016 05:26 PM, Luis Machado wrote:
> On 11/21/2016 06:31 AM, Matthias Pfaller wrote:
>> Hi,
>>
>> in order to have per thread watch and break points I resorted to report
>> "multiprocess+;" and put each thread into its very own "process". But
>> when I did this, I got the following display:
>>
>> (gdb) info inferiors
>>   Num  Description       Executable
>> * 1    process 536909700 firmware/firmware.elf
>> (gdb) info threads
>>   Id   Target Id         Frame
>>   1    Thread 536949956.536949956 (gdbstub      R    00000000       0)
>> (running)
>>   2    Thread 536948708.536948708 (lightshow    S    2000fac4      36)
>> (running)
>>   3    Thread 536947332.536947332 (dspleds      S    2000faf2      33)
>> ..
>> (gdb)
>>
>> I don't think this is the way this should work. I did a simple patch to
>> remote.c and inferior.c. Now I get (don't mind the different lwp/pid
>> format):
>> (gdb) info inferiors
>>   Num  Description Executable
>>   1    200134c4    firmware.elf
>>   2    20012fe4    firmware.elf
>> ...
>> (gdb) info threads
>>   Id   Target Id         Frame
>>   1.1  200134c4 (gdbstub      R    00000000       0) (running)
>>   2.1  20012fe4 (lightshow    S    2000fac4      29) (running)
>> ...
>> * 27.1 20009784 (idle         R    00000000       0) (running)
>> (gdb)
>> [patch omitted]
>> Can anybody tell me how this is used at the moment and weather my patch
>> is interfering with the current usage?
>>
>> I have done a second patch that limits stop_all_threads and
>> restart_threads to the tasks belonging to the stopped inferior because I
>> cannot stop all threads while debugging. Is there any interest in this?
>>
>> regards, Matthias
>>
> 
> Sorry, i don't think this patch is acceptable as is. GDB would need to
> learn how to handle thread-specific break/watch requests. That will take
> a bit more work though.
> 
> The above patch does interfere with the way GDB handles things. I
> believe the testsuite will show regressions if you run it with this
> patch applied.

Actually my patch should not interfere at all (I hope ...).

At the moment gdb inserts global watch and break points into all
inferiors that get debugged. Only when gdbarch_has_global_breakpoints
returns true the breakpoint is inserted into just one inferior.

In all other cases the correct inferior has to be selected before
planting the break point. When I finally understood this, I made my
target return "multiprocess+;". When I return the thread list to gdb I
place every thread into its very own process. That way gdb automatically
does the correct thing when I place a thread specific break point (i.e.
selecting the correct general process before setting the break point).

But when I reported the thread list gdb would not construct a correct
inferior list (with remote.c). My patch tries to fix this. Once all this
might have worked for the only arch that returns
gdbarch_has_global_breakpoints as true (dicos). But I just can't see how
this would work in the normal case.

The other thing I tried to fix are gdb crashes on disconnect/reconnect
with a multiprocess+ target.

regards, Matthias
-- 
Matthias Pfaller                          Software Entwicklung
marco Systemanalyse und Entwicklung GmbH  Tel   +49 8131 5161 41
Hans-Böckler-Str. 2, D 85221 Dachau       Fax   +49 8131 5161 66
http://www.marco.de/                      Email leo@marco.de
Geschäftsführer Martin Reuter             HRB 171775 Amtsgericht München

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature