Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Kevin Pouget <kevin.pouget@gmail.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb@sourceware.org
Subject: Re: GNU Tools Cauldron 2012 - BoF: Roadmap
Date: Mon, 06 Feb 2012 17:42:00 -0000	[thread overview]
Message-ID: <CAPftXUK2mZup1bN_Zf6wRfvuDtuTyf7auXb+kxFB=htofBxtLg@mail.gmail.com> (raw)
In-Reply-To: <87liomz557.fsf@gnu.org>

On Wed, Feb 1, 2012 at 9:10 PM, Jose E. Marchesi <jemarch@gnu.org> wrote:
>
>    It would be nice to make a general GDB BoF there, are more GDB contributors
>    planning to attend Cauldron?
>
> ATM I am just getting familiar with the sims stuff and working in a
> private git repo, so I cannot be considered as a contributor (yet), but
> I will be attending the Cauldron :)

hello,

I'll participate as well, and I registered myself to give a
presentation about my PhD on-going work, as described in the abstract
below.


Title: Supporting Parallel Component Debugging Using the GDB Python Interface
Authors: Kevin POUGET, Miguel SANTANA, Jean-François MEHAUT and Vania
Marangozova-Martin
Abstract:
In this presentation, we will introduce the work we have
undertaken in a join R&D effort of STMicroelectronics and the
Laboratoire d'Informatique de Grenoble on the GDB project.

In the context of parallel and embedded computing, debugging is well-
recognized as a complex activity. Nowadays, such applications are not
developed anymore from scratch, relying only on the programming
language primitives. Instead, they lean upon more advanced programming
models allowing an easier expression of parallelism.

Interactive debuggers like GDB evolved from their earlier times when
they could only handle machine instructions to support the source
languages used by developers to write their applications. We believe
that their next evolution could be the support of programming models,
which would help the developers to manipulate higher level
abstractions like the entities or communication mechanisms defined by
the programming model. These abstractions will have the advantage of
being closer to the concepts the developer dealt with during
development time and they will help her to keep focused on application
execution behaviour.

Hence, our work consists in improving GDB towards the support of such
programming models. On top of GDB's Python interface, and extending it
with contributed patches whenever it was required, we prepared a
framework supporting the debugging of an ST home-made embedded
component framework for MPSoC systems, running on an x86
simulator. The presentation will detail how we leveraged GDB to gather
relevant runtime information about the component framework and the set
of new features we developed, along with use-cases about their usage.


      reply	other threads:[~2012-02-06 17:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-01 18:17 Jan Kratochvil
2012-02-01 20:11 ` Jose E. Marchesi
2012-02-06 17:42   ` Kevin Pouget [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='CAPftXUK2mZup1bN_Zf6wRfvuDtuTyf7auXb+kxFB=htofBxtLg@mail.gmail.com' \
    --to=kevin.pouget@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    /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