public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: "Tye, Tony" <Tony.Tye@amd.com>
To: It's Me <aghozzo@gmail.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: RE: ROCm (Rocgdb debugger) use queues to pass debug commands?
Date: Mon, 1 Feb 2021 22:02:29 +0000	[thread overview]
Message-ID: <BN8PR12MB33939954700014EE52B05B9E97B69@BN8PR12MB3393.namprd12.prod.outlook.com> (raw)
In-Reply-To: <AACF8291-06DC-4500-9E4F-04676474C717@gmail.com>

[AMD Official Use Only - Internal Distribution Only]

The breakpoints are done the same way as on the CPU. So just look at how the CPU does it. Gdb writes trap instructions into the code using ptrace poke or /proc/fs. When the processor (CPU or GPU) executes the  breakpoint instruction is causes a “signal” that gets reported through the ioctl to the gdb process.

The AMD GPU Debugger API is open source in github and has a full doxygen documentation. Also, when you install ROCm the documentation is installed in /opt/rocm/share/doc .

Thanks,
-Tony

From: It's Me <aghozzo@gmail.com>
Sent: Monday, February 1, 2021 4:30 PM
To: Tye, Tony <Tony.Tye@amd.com>
Cc: gdb@sourceware.org
Subject: Re: ROCm (Rocgdb debugger) use queues to pass debug commands?

[CAUTION: External Email]

Hi Tony ,

I appreciate the reply , thanks .

So just to confirm the commands are not encapsulated in a packet and pushed into queues in HSA AQL queues .

Can you please give a high level path for setting a breakpoint from user land to the GPU ( how the flow happen through the software stack )

Also if there is not much trouble can you also provide any APIs for passing a breakpoint . I looked through rocgdb / rocgdb driver code / ROCm API .. and the clear path is not clear for me ..

Again thanks a lot for the help and the reply . Appreciated

On Feb 1, 2021, at 12:24 PM, Tye, Tony <Tony.Tye@amd.com<mailto:Tony.Tye@amd.com>> wrote:
[AMD Official Use Only - Internal Distribution Only]

rocgdb uses a driver that provides an ioctl interface that is similar in concept to what the ptrace and waitpid do for a CPU. There is a Debugger API library that uses the ioctl interface to provide an general way to control the GPU threads. There is a rocm target that is part of gdb that uses the Debugger ABI to allow GPU threads to be controlled just like CPU threads. All the code is open source.

Thanks,
-Tony

-----Original Message-----
From: Gdb <gdb-bounces@sourceware.org<mailto:gdb-bounces@sourceware.org>> On Behalf Of It's Me via Gdb
Sent: Monday, February 1, 2021 3:18 PM
To: gdb@sourceware.org<mailto:gdb@sourceware.org>
Subject: ROCm (Rocgdb debugger) use queues to pass debug commands?

[CAUTION: External Email]

Hi ,

In a heterogenous environment , how ROCm / rocgdb pass its debug commands ( example : breakpoint command) to the target ( Example a GPU) . Does the debugger queue it’s debug commands using HSA queues ? If that’s not that case how ?

What is the role of the driver in this case .

Thanks

      reply	other threads:[~2021-02-01 22:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01 20:17 It's Me
2021-02-01 20:24 ` Tye, Tony
2021-02-01 21:29   ` It's Me
2021-02-01 22:02     ` Tye, Tony [this message]

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=BN8PR12MB33939954700014EE52B05B9E97B69@BN8PR12MB3393.namprd12.prod.outlook.com \
    --to=tony.tye@amd.com \
    --cc=aghozzo@gmail.com \
    --cc=gdb@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).