All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] toolchain-external: Introduce gdb_copy option
Date: Mon, 18 Nov 2019 14:24:25 +0100	[thread overview]
Message-ID: <20191118142425.4a31a41d@windsurf.home> (raw)
In-Reply-To: <DM6PR12MB2876311450E0AA31BC3CA84CD94D0@DM6PR12MB2876.namprd12.prod.outlook.com>

Hello Evgeniy,

Top-posting on most open-source mailing list is not considered to be a
good practice. If possible, you should try to do bottom posting. Thanks!

On Mon, 18 Nov 2019 12:01:56 +0000
Evgeniy Didin <Evgeniy.Didin@synopsys.com> wrote:

> Using prebuilt toolchain besides the speedup of build has another advantage - in most cases that toolchain was well tested
> and guaranteed to work stable.

True.

> And without copything the prebuilt GDB debugger to target we need to build it from sources,
> which version is defined in package/gdb and most likely is different to prebuilt toolchain version. gdbserver ver. XXX may not be
> able to work with GDB ver. YYY.

Wait, this argument does not make sense: your patch is about copying
gdb to the target, so it is completely unrelated to gdbserver.

You can already today use the cross-gdb of the external toolchain
together with the gdbserver of the external toolchain: it is precisely
because there is often some kind of version dependency between both
that we have a Buildroot option to copy the toolchain-provided
gdbserver to the target.

However your patch is about copying the full *target* gdb to the target
filesystem, which again is completely unrelated to gdbserver.

> In our case we have dynamically linked minimalistic GDB with only Libc components dependencies:
> --------------------------------8<--------------------------------
>  $ arc-linux-objdump  -hx gdb | grep  NEEDED
>   NEEDED               libdl.so.2
>   NEEDED               libstdc++.so.6
>   NEEDED               libm.so.6
>   NEEDED               libgcc_s.so.1
>   NEEDED               libc.so.6

This is true today for your specific toolchain, but it is very possible
that in the future you will enable support for ncurses/readline, for
python, for expat, or other features. And then it will simply not work.

> In linaro/arm/mips toolchains there is no prebuilt GDB debugger,
> so I guess we should add additional  conditional "depends on BR2_arc".
> Will it be acceptable?

I think I would only find it acceptable if there was a check that the
target gdb provided by the toolchain only had dependencies on the C
library (libdl, libstdc++, libm, libc, etc.), and no other dependencies.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

      reply	other threads:[~2019-11-18 13:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18  8:00 [Buildroot] [PATCH] toolchain-external: Introduce gdb_copy option Evgeniy Didin
2019-11-18  8:11 ` Thomas Petazzoni
2019-11-18 12:01   ` Evgeniy Didin
2019-11-18 13:24     ` Thomas Petazzoni [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=20191118142425.4a31a41d@windsurf.home \
    --to=thomas.petazzoni@bootlin.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.