| Message ID | 1344251847-7709-3-git-send-email-sonic.adi@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
Le Mon, 6 Aug 2012 19:17:27 +0800, Sonic Zhang <sonic.adi@gmail.com> a écrit : > From: Sonic Zhang <sonic.zhang@analog.com> > > Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> > --- > toolchain/gdb/Config.in | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/toolchain/gdb/Config.in b/toolchain/gdb/Config.in > index fd6956b..8a440d8 100644 > --- a/toolchain/gdb/Config.in > +++ b/toolchain/gdb/Config.in > @@ -14,14 +14,13 @@ comment "Gdb debugger for the target needs WCHAR support in toolchain" > > config BR2_PACKAGE_GDB_SERVER > bool "Build gdb server for the Target" > - depends on !BR2_TOOLCHAIN_EXTERNAL > help > Build the gdbserver stub to run on the target. > A full gdb is needed to debug the progam. > > config BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY > bool "Copy gdb server to the Target" > - depends on BR2_TOOLCHAIN_EXTERNAL > + depends on BR2_TOOLCHAIN_EXTERNAL && !BR2_PACKAGE_GDB_SERVER > help > Copy the gdbserver provided by the external toolchain to the > target. Is this really a good idea? For compatibility reasons, we generally want the gdbserver on the target to have the same version as the cross gdb on the development machine. Therefore, in the external toolchain case, it sounds like a really bad idea to let the user build its own gdbserver instead of using the one of the external toolchain. I know the Blackfin toolchains are not providing their own gdbserver (but they provide a cross gdb), but in my opinion, it's a bug that should be fixed in the build process of the Blackfin toolchains: they should include their own gdbserver, just like the Linaro and Sourcery CodeBench toolchains do. Best regards, Thomas
On Tue, Aug 7, 2012 at 11:22 AM, Zhang, Sonic <Sonic.Zhang@analog.com> wrote: > Hi Thomas, > >>-----Original Message----- >>From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com] >>Sent: Monday, August 06, 2012 8:55 PM >>To: Sonic Zhang >>Cc: Peter Korsgaard; buildroot@busybox.net; buildroot-devel@lackfin.uclinux.org; >>Zhang, Sonic >>Subject: Re: [Buildroot] [PATCH 3/3] buildroot: toolchain: Allow to build gdbserver >>when external toolchain is selected. >> >>Le Mon, 6 Aug 2012 19:17:27 +0800, >>Sonic Zhang <sonic.adi@gmail.com> a écrit : >> >>> From: Sonic Zhang <sonic.zhang@analog.com> >>> >>> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> >>> --- >>> toolchain/gdb/Config.in | 3 +-- >>> 1 files changed, 1 insertions(+), 2 deletions(-) >>> >>> diff --git a/toolchain/gdb/Config.in b/toolchain/gdb/Config.in >>> index fd6956b..8a440d8 100644 >>> --- a/toolchain/gdb/Config.in >>> +++ b/toolchain/gdb/Config.in >>> @@ -14,14 +14,13 @@ comment "Gdb debugger for the target needs WCHAR >>support in toolchain" >>> >>> config BR2_PACKAGE_GDB_SERVER >>> bool "Build gdb server for the Target" >>> - depends on !BR2_TOOLCHAIN_EXTERNAL >>> help >>> Build the gdbserver stub to run on the target. >>> A full gdb is needed to debug the progam. >>> >>> config BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY >>> bool "Copy gdb server to the Target" >>> - depends on BR2_TOOLCHAIN_EXTERNAL >>> + depends on BR2_TOOLCHAIN_EXTERNAL >>&& !BR2_PACKAGE_GDB_SERVER >>> help >>> Copy the gdbserver provided by the external toolchain to the >>> target. >> >>Is this really a good idea? For compatibility reasons, we generally >>want the gdbserver on the target to have the same version as the cross >>gdb on the development machine. Therefore, in the external toolchain >>case, it sounds like a really bad idea to let the user build its own >>gdbserver instead of using the one of the external toolchain. >> > > This is an option for developers who want to develop/debug gdb server or want to use an alternative version. > The developer is responsible to ensure the compatibility. > >>I know the Blackfin toolchains are not providing their own gdbserver >>(but they provide a cross gdb), but in my opinion, it's a bug that >>should be fixed in the build process of the Blackfin toolchains: they >>should include their own gdbserver, just like the Linaro and Sourcery >>CodeBench toolchains do. >> > > I include ADI blackfin GNU toolchain developer Stuart for your question. > Because Stuart is out these days, I cc David as well. Regards, Sonic
Hello, Le Wed, 8 Aug 2012 17:29:20 +0100, "Henderson, Stuart" <Stuart.Henderson@analog.com> a écrit : > Since Sonic's linux distro has gdbserver built into it anyway (built > using the appropriate version of the toolchain), I don't think > providing gdbserver in the toolchain as well would provide any > particular benefit to the end user. Is there a scenario where having > gdbserver in the toolchain is going to help the user? I'd happily > introduce it, if so. Well, my personal experience (and I've heard this experience from several other people has well) is that to avoid problems the gdbserver version you're using should be the same as the cross-gdb used to connect to this gdbserver. Therefore, it makes sense for a toolchain to provide both cross-gdb *and* gdbserver, or none of them, but it doesn't make much sense to offer just cross-gdb without a gdbserver. As I was mentioning before, Linaro toolchains, Sourcery CodeBench toolchains do that. Best regards, Thomas
Hello, Le Tue, 14 Aug 2012 12:06:38 +0100, "Henderson, Stuart" <Stuart.Henderson@analog.com> a écrit : > >Well, my personal experience (and I've heard this experience from several other people has well) > >is that to avoid problems the gdbserver version you're using should be the same as the cross-gdb > >used to connect to this gdbserver. Therefore, it makes sense for a toolchain to provide both cross-gdb > >*and* gdbserver, or none of them, but it doesn't make much sense to offer just cross-gdb without a > >gdbserver. As I was mentioning before, Linaro toolchains, Sourcery CodeBench toolchains do that. > > This seems reasonable, however we only support matching releases of the toolchain/u-boot/linux, so the result is much the same. > i.e. The 2012R1 release of the toolchain is used to build the 2012R1 release of u-boot and linux. The latter of which contains the correct version of gdbserver for the 2012R1 release of the toolchain. I am not sure to understand: why would gdbserver be part of your "linux" release? Linux is the kernel, was does it has to do with gdbserver. > However, like I said, I certainly don't have any strong objections to having gdbserver in the toolchain package as well. I'll take a look at how other people package it and see what Sonic's thoughts are on it when we're doing the next release. Ok, thanks! Thomas
diff --git a/toolchain/gdb/Config.in b/toolchain/gdb/Config.in index fd6956b..8a440d8 100644 --- a/toolchain/gdb/Config.in +++ b/toolchain/gdb/Config.in @@ -14,14 +14,13 @@ comment "Gdb debugger for the target needs WCHAR support in toolchain" config BR2_PACKAGE_GDB_SERVER bool "Build gdb server for the Target" - depends on !BR2_TOOLCHAIN_EXTERNAL help Build the gdbserver stub to run on the target. A full gdb is needed to debug the progam. config BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY bool "Copy gdb server to the Target" - depends on BR2_TOOLCHAIN_EXTERNAL + depends on BR2_TOOLCHAIN_EXTERNAL && !BR2_PACKAGE_GDB_SERVER help Copy the gdbserver provided by the external toolchain to the target.