[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Anders Darander]

Hi,

I've attached a patch (formatted by git), which adds the possibility
to have buildroot install the already compiled gdbserver from an
external toolchain.

To  make sure that debuging works, it is preferred if both the host
crosscompiler gdb and gdbserver is built from the same gdb version. If
we take the gdbserver from the external toolchain, this is guaranteed.

I'm not sure that the implementation is the best, it migth be  a
little bit "hackish". Looking forward to some comments for
improvement.

Regards,
Anders
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-gdbserver-from-external-toolchain.patch
Type: application/octet-stream
Size: 1781 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20091022/ce01c088/attachment.obj>

[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Yann E. MORIN]

Hello Anders!
Hello All!

On Thursday 22 October 2009 11:47:52 Anders Darander wrote:
> To  make sure that debuging works, it is preferred if both the host
> crosscompiler gdb and gdbserver is built from the same gdb version. If
> we take the gdbserver from the external toolchain, this is guaranteed.

Yes, this is highly suggested that the cross-gdb and the gdbserver are
from the same /version/ of gdb, as they have to speak the same protocol
on the wire, and that can change between releases.

> I'm not sure that the implementation is the best, it migth be  a
> little bit "hackish". Looking forward to some comments for
> improvement.

I'm afraid this is a bit too crosstool-NG centric. OTOH, there's no clean
way to know where in an external toolchain we should look for the gdbserver.

This is some API that crosstool-NG should expose to outside: tell me where
in can find the {gdbserver,duma,whatever} and the corresponding dependencies
(libs, scripts...).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'

[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Anders Darander]

Hi Yann,

(I'm also adding a CC to the mailing list; I think I might have
replied in a wrong way earlier by mistake)...

On Fri, Oct 23, 2009 at 19:26, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
> Hello Anders!
>
> On Friday 23 October 2009 08:26:52 Anders Darander wrote:
>> On Thu, Oct 22, 2009 at 19:40, Yann E. MORIN
>> <yann.morin.1998@anciens.enib.fr> wrote:
>> > I'm afraid this is a bit too crosstool-NG centric. OTOH, there's no clean
>> > way to know where in an external toolchain we should look for the gdbserver.
>> Yes, it is quite likely that it relies to heavily on the external
>> toolchain being generated by crosstool-NG. OTOH, as there is no clean
>> way to handle it, this might be the best way anyway? Possibly adding
>> an extra option where one could point out the location of the
>> gdbserver?
>
> Yes, I know. I was just saying that (for now) an external toolchain could
> be generated by something else than crosstool-NG, so we know what the
> patch would imply, and that it may break.

Yes, this is certainly very true, and it is also the use case I got to
think of when reading your earlier reply. However, unless the
configuration system of buildroot can determine that the external
toolchain is built by crosstool-NG, I think the best option we have is
to rely on an extended helptext.

> I am aware that there has recently been a thread about buildroot relying
> on extrernally-built toolchains, and use crosstool-NG to build it: we
> discussed the subject in Grenoble last WE with Peter, Thomas and Co.
> (BTW, I am the maintainer of crosstool-NG).

Well, even though I'm aware of that discussion (and I'm supporting
such a move), I had not made that coupling with this issue earlier. If
buildroot goes that way, than this whole arrangement of finding
gdbserver would probably be made a lot easier...

(By the way, I know that you're the maintainer of crosstool-NG. A huge
thank you for your work with crosstool-NG, I'm really enjoying it when
creating cross-toolchains).

>> If the external toolchain from some other source do not contain
>> gdbserver, the old way of letting buildroot build the gdbserver is
>> still available. Although, this should probably be added to the help
>> text of the new option.
>
> Agreed.
>
>> > This is some API that crosstool-NG should expose to outside: tell me where
>> > in can find the {gdbserver,duma,whatever} and the corresponding dependencies
>> > (libs, scripts...).
>> This would definitely be the best way. Although to make it really
>> usefull, it would have to be supported by more toolchains than the
>> ones from crosstool-NG... Otherwise we would still end up being
>> crosstool-NG-centric...
>
> Agreed as well! But, in the case that buildroot eventually relies on
> crosstool-NG, then it should be easy for buildroot to _ask_ for the
> gdbserver, rather than relying on hard-coded paths (crosstool-NG being
> a separate project, it may change the place where the gdbserver is).

Yes, that is true. I had momentarily forgot about those plans. Then an
API would certainly make sense, even if only crosstool-NG implements
it.

Thanks again!
Best regards,
Anders

[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Lionel Landwerlin]

Le jeudi 22 octobre 2009 ? 11:47 +0200, Anders Darander a ?crit :
> Hi,
> 
> I've attached a patch (formatted by git), which adds the possibility
> to have buildroot install the already compiled gdbserver from an
> external toolchain.
> 
> To  make sure that debuging works, it is preferred if both the host
> crosscompiler gdb and gdbserver is built from the same gdb version. If
> we take the gdbserver from the external toolchain, this is guaranteed.
> 
> I'm not sure that the implementation is the best, it migth be  a
> little bit "hackish". Looking forward to some comments for
> improvement.
> 
> Regards,
> Anders

Hi Anders,

Interesting patch ;)

Maybe you could add

	depends on BR2_TOOLCHAIN_EXTERNAL

to your BR2_TOOLCHAIN_EXTERNAL_GDBSERVER option.

Regards,

-- 
Lionel Landwerlin <llandwerlin@gmail.com>

[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Lionel Landwerlin]

Le vendredi 23 octobre 2009 ? 08:19 +0200, Anders Darander a ?crit :
> Hi Lionel,
> 
> On Thu, Oct 22, 2009 at 21:40, Lionel Landwerlin <llandwerlin@gmail.com> wrote:
> > Maybe you could add
> >
> >        depends on BR2_TOOLCHAIN_EXTERNAL
> >
> > to your BR2_TOOLCHAIN_EXTERNAL_GDBSERVER option.
> 
> Sure that would be no problem.
> 
> However, I don't really see what that would gain us. Currently, the
> option in the menu is guarded the the 'if
> BR2_TOOLCHAIN_EXTERNAL'-clause that extends to the whole Config.in I'm
> touching... Thus, I believe that we already have this implicitly. Or
> am I missing something else that an added depend-statement would gain
> us?
> 

Yeah sorry, I didn't see the 'if BR2_TOOLCHAIN_EXTERNAL' at the top of
the file. Forget about it :)


-- 
Lionel Landwerlin <llandwerlin@gmail.com>

[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Anders Darander]

On Fri, Oct 23, 2009 at 08:49, Lionel Landwerlin <llandwerlin@gmail.com> wrote:
>
> Yeah sorry, I didn't see the 'if BR2_TOOLCHAIN_EXTERNAL' at the top of
> the file. Forget about it :)

No problem, as that line was outside of the patch, it's easy to miss...

Regards,
Anders

[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Thomas Petazzoni]

Hi,

Le Thu, 22 Oct 2009 11:47:52 +0200,
Anders Darander <anders.darander@gmail.com> a ?crit :

> I've attached a patch (formatted by git), which adds the possibility
> to have buildroot install the already compiled gdbserver from an
> external toolchain.
> 
> To  make sure that debuging works, it is preferred if both the host
> crosscompiler gdb and gdbserver is built from the same gdb version. If
> we take the gdbserver from the external toolchain, this is guaranteed.
> 
> I'm not sure that the implementation is the best, it migth be  a
> little bit "hackish". Looking forward to some comments for
> improvement.

This feature is of course very welcome, but I'd like to see the
external toolchain support to be extended to toolchains not generated
by Crosstool-NG (Codesourcery toolchains, for example, are still on my
TODO-list).

Can we imagine a way of making this more generic ? Maybe we could
detect the toolchain ?type? and act differently depending on this type ?

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Lionel Landwerlin]

Le samedi 24 octobre 2009 ? 18:25 +0200, Thomas Petazzoni a ?crit :
> Hi,
> 
> Le Thu, 22 Oct 2009 11:47:52 +0200,
> Anders Darander <anders.darander@gmail.com> a ?crit :
> 
> > I've attached a patch (formatted by git), which adds the possibility
> > to have buildroot install the already compiled gdbserver from an
> > external toolchain.
> > 
> > To  make sure that debuging works, it is preferred if both the host
> > crosscompiler gdb and gdbserver is built from the same gdb version. If
> > we take the gdbserver from the external toolchain, this is guaranteed.
> > 
> > I'm not sure that the implementation is the best, it migth be  a
> > little bit "hackish". Looking forward to some comments for
> > improvement.
> 
> This feature is of course very welcome, but I'd like to see the
> external toolchain support to be extended to toolchains not generated
> by Crosstool-NG (Codesourcery toolchains, for example, are still on my
> TODO-list).
> 
> Can we imagine a way of making this more generic ? Maybe we could
> detect the toolchain ?type? and act differently depending on this type ?
> 

What comes up to your mind by "type" ?
Here is a short list to start with :
	1) uclibc vs glibc
	2) contains tools strongly linked to the core toolchain :
		- gdbserver / gdb / gcc

What else ?


Regards,

-- 
Lionel Landwerlin <llandwerlin@gmail.com>

[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Yann E. MORIN]

Lionel,
All,

On Saturday 24 October 2009 19:41:07 Lionel Landwerlin wrote:
> Le samedi 24 octobre 2009 ? 18:25 +0200, Thomas Petazzoni a ?crit :
> > Can we imagine a way of making this more generic ? Maybe we could
> > detect the toolchain ?type? and act differently depending on this type ?
> What comes up to your mind by "type" ?
> Here is a short list to start with :
> 	1) uclibc vs glibc

I think Thomas was pointing to toolchains coming from different sources and
vendors:
 - crosstool-NG
 - CodeSourcery
 - OSELAS:Toolchain()
 - OpenWRT
 - manually built
 - ...

and not about what the toolchain is based upon ( and in your example, you
were missing eglibc ;-) ).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'

[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Anders Darander]

Hi Thomas,

On Sat, Oct 24, 2009 at 17:25, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> This feature is of course very welcome, but I'd like to see the
> external toolchain support to be extended to toolchains not generated
> by Crosstool-NG (Codesourcery toolchains, for example, are still on my
> TODO-list).

Yes, this would definitely be desirable.

> Can we imagine a way of making this more generic ? Maybe we could
> detect the toolchain ?type? and act differently depending on this type ?

Currently I see no way on changing the menuentries depending on the
toolchain type (here I assume type is Crosstool-NG, Codesourcery,
etc...) Thus we will not know if there is any gdbserver in the
toolchain...

However, in the ext-tool.mk, we should be able to at least query the
toolchain for the configuration and parse that information, and decide
from what source the toolchain comes.

I could implement such a feature, although, I'd probably only be able
to verify that it works on a crosstool-NG based toolchain. The
necessary logics for other toolchains will have to be provided by
someone using them.

I'll see if I can squeeze such an implementation into the work
schedule for this week.

Regards,
Anders

[Buildroot] [RFC; PATCH v2] Use gdbserver from external toolchain

[Anders Darander]

Hi all,

On Mon, Oct 26, 2009 at 08:32, Anders Darander
<anders.darander@gmail.com> wrote:
> Hi Thomas,
>
> On Sat, Oct 24, 2009 at 17:25, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> This feature is of course very welcome, but I'd like to see the
>> external toolchain support to be extended to toolchains not generated
>> by Crosstool-NG (Codesourcery toolchains, for example, are still on my
>> TODO-list).
>
> Yes, this would definitely be desirable.
>
>> Can we imagine a way of making this more generic ? Maybe we could
>> detect the toolchain ?type? and act differently depending on this type ?
>
> Currently I see no way on changing the menuentries depending on the
> toolchain type (here I assume type is Crosstool-NG, Codesourcery,
> etc...) Thus we will not know if there is any gdbserver in the
> toolchain...
>
> However, in the ext-tool.mk, we should be able to at least query the
> toolchain for the configuration and parse that information, and decide
> from what source the toolchain comes.

Attached is a version 2 of the patch.

Main differences after feedback:
*) The help text in Config.in states that it only works for
crosstool-ng generated toolchains.
*) The copy function in ext-tool.mk checks to see if the toolchain is
generated by crosstool-ng, otherwise it'll bail out. The functionality
to strip the binary has also been added, per copy_toolchain_lib_root.

The copy_toolchain_debugroot is still a bit hackish, though. However,
anyways, I think that it starts to be usable. Once (if) crosstool-ng
gets an API to query for the debug-root, it should be easy to replace
the current hard-coded sets of path's.

Looking forward to a new sets of comments, and hopefully in the end a
commit of the patch.
Regards,
Anders
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-gdbserver-from-external-toolchain.patch
Type: application/octet-stream
Size: 3209 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20091026/5825f26c/attachment.obj>

[Buildroot] [RFC; PATCH v2] Use gdbserver from external toolchain

[Thomas Petazzoni]

Hi Anders,

Le Mon, 26 Oct 2009 11:22:28 +0100,
Anders Darander <anders.darander@gmail.com> a ?crit :

> Attached is a version 2 of the patch.

Unless I'm mistaken, I think that you sent the incorrect version of the
patch.

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

[Buildroot] [RFC; PATCH v2] Use gdbserver from external toolchain

[Anders Darander]

Hi Thomas,

On Mon, Oct 26, 2009 at 12:16, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hi Anders,
>
> Le Mon, 26 Oct 2009 11:22:28 +0100,
> Anders Darander <anders.darander@gmail.com> a ?crit :
>
>> Attached is a version 2 of the patch.
>
> Unless I'm mistaken, I think that you sent the incorrect version of the
> patch.

I've checked the sent mail, and the attachement in my last mail is
indeed the new patch. I should probably have updated the headers in
the patch-file from git.
(On and off, I'm still struggling a little bit with git format-patch.
Currently it seems that git keeps my original date and time of the
patch...).

Regards,
Anders

[Buildroot] [RFC; PATCH v2] Use gdbserver from external toolchain

[Anders Darander]

Hi all,

On Mon, Oct 26, 2009 at 15:07, Anders Darander
<anders.darander@gmail.com> wrote:
> I've checked the sent mail, and the attachement in my last mail is
> indeed the new patch. I should probably have updated the headers in
> the patch-file from git.
> (On and off, I'm still struggling a little bit with git format-patch.
> Currently it seems that git keeps my original date and time of the
> patch...).

Attached is a newly generated patch-file, with new timestamps. To
better fit in with the git tree it is based on.

-- 
Anders Darander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-gdbserver-from-external-toolchain.patch
Type: application/octet-stream
Size: 3209 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20091026/d02347c2/attachment.obj>

[Buildroot] [RFC; PATCH] Use gdbserver from external toolchain

[Yann E. MORIN]

Hello all!

On Saturday 24 October 2009 18:25:38 Thomas Petazzoni wrote:
> Le Thu, 22 Oct 2009 11:47:52 +0200,
> Anders Darander <anders.darander@gmail.com> a ?crit :
> > I've attached a patch (formatted by git), which adds the possibility
> > to have buildroot install the already compiled gdbserver from an
> > external toolchain.
> This feature is of course very welcome, but I'd like to see the
> external toolchain support to be extended to toolchains not generated
> by Crosstool-NG (Codesourcery toolchains, for example, are still on my
> TODO-list).

Yes, the idea is nice, and having a generic way to get such info is
most wanted. Unfortunately, I'm afraid that most toolchains will not
provide such means (of course we can try to push it, and it will be
easier for some than for others).

> Can we imagine a way of making this more generic ? Maybe we could
> detect the toolchain ?type? and act differently depending on this
> type ? 

Hmmm... That would require quite some knowledge about the toolchain
generators, and each may change paths as they see fit, and we'd be
lagging behind very quickly...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'