Re: Response to gdb multithreaded breakpoints' problem

On Tue, May 13, 2014 at 6:07 AM, Sophia Rodina <[email protected]> wrote:
>
> On 11 May 2014 07:27, Luis Machado<[email protected]
> <mailto:[email protected]>>wrote:
>
>     On 05/10/2014 06:56 PM, Sofia wrote:
>
>         I'm writing my GDB stub and trying to set breakpoints on
>         different threads.
>         When I don't ask GDB about the number of threads, It works fine
>         as a single-
>         threaded application and breakpoints are set correctly. But when
>         I enter -
>         'info threads', something strange happens.
>
>         Firstly, GDB reads the contents of all threads' registers(it's
>         OK). Then I
>         enter 'continue' and see that breakpoints are not set at all
>         threads my
>         program has. I don't understand why, but the packet
>         Z0(breakpoint packet) is
>         only sent to inactive thread. The documentation says that if the
>         thread id is
>         not specified, breakpoints will be set at all threads. What's
>         wrong with this
>         or where can I read about such GDB behavior?
>
>
>
>
>     Is this a software breakpoint (Z0/z0) or a hardware breakpoint we
>     are talking about?
>
>     A software breakpoint should be valid for all threads if the threads
>     are executing a shared piece of code. If these breakpoints are not
>     triggering, we may have a bug somewhere.
>
>     For hardware breakpoints, the target code (in this case, the remote
>     stub) is responsible for replicating the hardware breakpoint
>     settings (register contents) to all threads upon their creation.
>
>     What version of GDB are you using?
>
>
> No, It's a software breakpoint. I set it as [b *addr].

The distinction between "software breakpoint" and "hardware
breakpoint" is how they are implemented on the target.
Either can be used to implement "b *addr".
The canonical example is i386(/amd64) where a "software breakpoint"
uses the "int3" instruction and a "hardware breakpoint" uses the i386
debug registers.

> My gdb-multiarch version is GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7
>
> How is breakpoints' setting implemented in gdb? I expect gdb to switch
> between all currently active threads and send (Z0, addr) packet to all
> of them. And it definitely doesn't do what I expect. So, how gdb should
> behave in such cases?

gdb leaves it to the stub to do whatever may be necessary to install
the breakpoint on all threads.
In the case of i386-linux, gdbserver monitors the creation of new
threads, and whenever a new thread is detected h/w breakpoints (or
watchpoints) are automagically installed in the new thread (since the
i386 debug registers are thread-specific).

gdb sets the breakpoint on only the inactive thread because at least
on linux the ptrace system call, which is used to install breakpoints,
can only be used on a thread that is stopped.
In the case of a "software breakpoint" (which is what I see being used
in your case: Z0) it is sufficient to only set it on one thread
because all threads share the same code space (and thus once set in
one thread it will be visible to all threads - at least conceptually -
if, e.g., a cache flush is needed in order to make the breakpoint
visible to all threads then the stub needs to do this).

> I attach my logs(packets and responses of gdbstub and gdb-client), maybe
> they will better explain what is going on.
> I divided it into several parts for easier navigation.
>
> 1.  INITIALIZATION
> 2.  AFTER INFO THREADS COMMAND
> 3. CONTINUE
> 4.  CTRL+C IN GDB
> 5. b *0xbff77660
> 6. CONTINUE AFTER BREAKPOINT SETTING

The relevant part is here:

GDB: Receiving the packet...
GDB: Packet Z0,bff77660,4#4e was received from host.
GDB: Sending acknowledgement :)
GDB(mp_find): Matchpoint of type 0 at addr bff77660 was not found
GDB: Breakpoint was set at addr bff77660, removed opcode = 81e03003 on vcpu 1
GDB: Response packet = ($OK#9a)

Question: Is it not possible for your stub to install the breakpoint
on all threads?