From: Simon Marchi <simon.marchi@polymtl.ca>
To: Artium Nihamkin <alkhimey@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: Need advice on writing gdb server for multiprocessor enviroment
Date: Sun, 17 Mar 2019 00:20:00 -0000 [thread overview]
Message-ID: <f1234f0506c010945ffef0751de1387b@polymtl.ca> (raw)
In-Reply-To: <CACvQLfXRrqffEqk3NEwYPyihb5Fs5zfijxvMs6b2gpid_kLzfw@mail.gmail.com>
On 2019-03-15 20:59, Artium Nihamkin wrote:
> Hi,
>
> We have a multiprocessor embedded system with built in hardware
> debugger
> that interface through a GPIB (IEEE-488) connection.
>
> A custom application acts as a debugger fronted and sends these GPIB
> commands.
>
> We were thinking of replacing this application with a gdb server with
> the
> eventual goal of debugging straight from a common, modern IDE. Using a
> gdb
> server seems like versatile and relatively easy to implement.
That's an awesome idea :)
> The problem is that it is not clear how gdb, and specifically RSP,
> works
> with multiprocessor systems. Should we model each processor as a
> thread?
The RSP doesn't really mandate anything, it depends how your programming
model works and at which level works. For example, if you debug
"bare-metal", modelling each processor/core as a thread is a common way
to do it.
If you have some kind of OS (even if really simple) that creates
thread/process-like things, you might want to model those as threads.
In the same way that when you connect to gdbserver running on x86, you
don't see the hardware cores as threads, you see the execution threads
of your program.
And if you have people who work at both levels (OS and appliation
level), nothing prevents you from offering both options.
> The custom application has special commands such halting all processors
> at
> once, discovering which processors are present, getting the status of
> each
> processor (running/failed), XIO commands etc.
> Additionally there are several memory types with overlapping address
> spaces
> that the debugger can read/write to.
Are these like separate data and program memories, or is there more to
it?
Since gdb uses a simple numerical type when referring to addresses
(CORE_ADDR), it doesn't support multiple address spaces naturally. The
trick used so far by multiple architectures (in-tree, there is only AVR
I believe) is to uses high bits in the address to identify the address
space. These bits are then not shown when an address is printed, so the
user would not see them. It's just an internal encoding.
> Can all these things work reasonably with gdb?
It all sounds like challenges that have been overcome in the past for
various architectures, so I would say yes.
Simon
prev parent reply other threads:[~2019-03-17 0:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-16 1:00 Artium Nihamkin
2019-03-17 0:20 ` Simon Marchi [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=f1234f0506c010945ffef0751de1387b@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=alkhimey@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).