From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2] gdb: convert to the package infrastructure
Date: Wed, 20 Mar 2013 15:21:22 +0100 [thread overview]
Message-ID: <20130320152122.0e661e86@skate> (raw)
In-Reply-To: <201303192134.32575.yann.morin.1998@free.fr>
Dear Yann E. MORIN,
On Tue, 19 Mar 2013 21:34:32 +0100, Yann E. MORIN wrote:
> There is a little inconsistency in the available choices:
> Toolchain --->
> [ ] Copy gdb server to the Target
>
> is still available, even if:
> Package Selection for the target --->
> Debugging, profiling and benchmark --->
> [*] gdb
> [*] gdbserver
>
> I think it does not make sense to both copy the gdbserver from the
> toolchain, *and* build our own version.
Yes. I don't think it's really "inconsistent", but can certainly be
improved. I was thinking of doing that sort of improvement as a second
step.
> Given that the cross-gdb and the gdbserver are tightly coupled one to
> the other, I think we should have these possibility expressed in the
> menuconfig:
>
> - copy gdbserver from the external toolchain
> --> this assumes that there is a cross-gdb in the toolchain
> --> we should not build our own host cross-gdb
> --> we should not build our gdbserver
> --> we can build the full gdb (on the target)
>
> - do not copy gdbserver from the toolchain
> --> we can build both our host cross-gdb and our gdbserver
> --> we can build the full gdb (on the target)
> --> if the user uses the cross-gdb from the external toolchain, and
> it breaks, then too bad for him/her.
>
> At the very least, the external gdbserver and our own should be mutually
> exclusive.
I generally agree with your proposal. Do you mind if I implement that
as a followup patch? The current patch is already a bit large to
review.
> Also, the host cross-gdb and the gdbserver should be compiled from the
> same version, otherwise you may experience breakage. Although the
> gdbserver protocol should be stable, experience has proven this is not
> always the case.
>
> So I would suggest that, if we build the gdb (on the target) and/or the
> gdbserver, then the host cross-gdb version should not be selectable, and
> should be deduced from the version used to build the gdb (on the target).
It is already the case. Look at gdb.mk:
------------------------------------------------------------------
GDB_VERSION = $(call qstrip,$(BR2_GDB_VERSION))
GDB_SITE = $(BR2_GNU_MIRROR)/gdb
# When no version is defined, it means that cross-gdb for the host has
# not been enabled, and we will only build gdbserver or gdb for the
# target. In this case, use the latest available version
# automatically.
ifeq ($(GDB_VERSION),)
ifeq ($(BR2_bfin),y)
GDB_VERSION = 6.6a
else ifeq ($(BR2_avr32),y)
GDB_VERSION = 6.7.1-avr32-2.1.5
GDB_SITE = ftp://www.at91.com/pub/buildroot/
else
GDB_VERSION = 7.5.1
endif
endif
------------------------------------------------------------------
As the comment explains, if you have selected cross-gdb, then
BR2_GDB_VERSION will be non-empty (defined in
package/gdb/Config.in.host) and we will use this version to build
gdbserver and the gdb on the target. If no cross-gdb has been selected,
then we will use some default version (6.6a, 6.7.1 or 7.5 depending on
the architecture).
Doesn't that solve the issue you're raising?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-03-20 14:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-19 19:11 [Buildroot] [PATCH v2] gdb: convert to the package infrastructure Thomas Petazzoni
2013-03-19 20:34 ` Yann E. MORIN
2013-03-20 14:21 ` Thomas Petazzoni [this message]
2013-03-20 18:18 ` Yann E. MORIN
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=20130320152122.0e661e86@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.