Patchwork debug/gdb: include expat for gdb-cross

login
register
mail settings
Submitter Trevor Woerner
Date March 2, 2013, 5:19 p.m.
Message ID <bfbfdaaea8592dd87f96.1362244746@suse64>
Download mbox | patch
Permalink /patch/224519/
State Rejected
Headers show

Comments

Trevor Woerner - March 2, 2013, 5:19 p.m.
# HG changeset patch
# User Trevor Woerner <twoerner@gmail.com>
# Date 1362239822 18000
# Node ID bfbfdaaea8592dd87f96ddea8637f5b17b194ad4
# Parent  f89f8e6f876679184acb66ea642e42c9e7cf2f44
debug/gdb: include expat for gdb-cross

Some boards, such as the ST Discovery, have a debugger interface which
can be queried for a device feature description which is provided in XML.
Therefore it would be nice to have expat available to make use of this
information.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>


--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - March 3, 2013, 2:02 p.m.
Trevor, All,

On Saturday 02 March 2013 Trevor Woerner wrote:
> # HG changeset patch
> # User Trevor Woerner <twoerner@gmail.com>
> # Date 1362239822 18000
> # Node ID bfbfdaaea8592dd87f96ddea8637f5b17b194ad4
> # Parent  f89f8e6f876679184acb66ea642e42c9e7cf2f44
> debug/gdb: include expat for gdb-cross
> 
> Some boards, such as the ST Discovery, have a debugger interface which
> can be queried for a device feature description which is provided in XML.
> Therefore it would be nice to have expat available to make use of this
> information.
> 
> Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> 
> diff -r f89f8e6f8766 -r bfbfdaaea859 scripts/build/debug/300-gdb.sh
> --- a/scripts/build/debug/300-gdb.sh	Mon Feb 25 21:19:31 2013 +0100
> +++ b/scripts/build/debug/300-gdb.sh	Sat Mar 02 10:57:02 2013 -0500
> @@ -16,6 +16,7 @@
>  
>      if [ "${CT_GDB_CROSS}" = y ]; then
>          do_gdb=y
> +        do_expat=y
>      fi

This is wrong:
  - 'do_expat' is used to detect whether the expat lib shall be downloaded
    and extracted;
  - 'do_expat' is then mis-used:
    - it is never used to build expat for the host, but is used to decide
      whether to enable/disable expat in the cross-gdb
    - it is used to decide whether to build expat for the target, but is
      always set when the native-gdb is selected, so the check is pointless.

What should be done is:
  - rename 'do_expat' to 'need_expat' (ditto for 'do_ncurses')
  - use 'need_expat' only to decide whether to download/extract libexpat
  - cross-gdb: always enable expat support
  - native-gdb: ditto

I'm on it. Thanks for the report! :-)

Regards,
Yann E. MORIN.
Trevor Woerner - March 3, 2013, 2:34 p.m.
Hi Yann,

Thanks for looking into this.

On Sun, Mar 3, 2013 at 9:02 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> This is wrong:
>   - 'do_expat' is used to detect whether the expat lib shall be downloaded
>     and extracted;
>   - 'do_expat' is then mis-used:
>     - it is never used to build expat for the host, but is used to decide
>       whether to enable/disable expat in the cross-gdb
>     - it is used to decide whether to build expat for the target, but is
>       always set when the native-gdb is selected, so the check is pointless.

So if I understand you correctly, the only thing the build needs to
determine is if expat needs to be included in the sysroot?

> What should be done is:
>   - rename 'do_expat' to 'need_expat' (ditto for 'do_ncurses')
>   - use 'need_expat' only to decide whether to download/extract libexpat
>   - cross-gdb: always enable expat support
>   - native-gdb: ditto

In other words, if the build doesn't interfere with gdb's ./configure,
gdb's ./configure will naturally look for and link in the host's
expat?

Best regards,
    Trevor

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - March 3, 2013, 2:58 p.m.
Trevor, All,

On Sunday 03 March 2013 Trevor Woerner wrote:
> On Sun, Mar 3, 2013 at 9:02 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > This is wrong:
> >   - 'do_expat' is used to detect whether the expat lib shall be downloaded
> >     and extracted;
> >   - 'do_expat' is then mis-used:
> >     - it is never used to build expat for the host, but is used to decide
> >       whether to enable/disable expat in the cross-gdb
> >     - it is used to decide whether to build expat for the target, but is
> >       always set when the native-gdb is selected, so the check is pointless.
> 
> So if I understand you correctly, the only thing the build needs to
> determine is if expat needs to be included in the sysroot?

Sorta. Crosstool-NG only builds a static version of libexpat, and never
installs it in the sysroot (ditto ncurses).

So, we only need to know whether we need to build expat (ncurses) for the
target, and point gdb's configure to the place we installed it.

The reason for not installing expat/ncurses in the sysroot is that the
libs are not part of the toolchain. They are only used for internal
components, and should not be exposed in the sysroot, in case the user
wants another version, or different compile flags, or a patched version.

This is purely internal to crosstool-NG.

> > What should be done is:
> >   - rename 'do_expat' to 'need_expat' (ditto for 'do_ncurses')
> >   - use 'need_expat' only to decide whether to download/extract libexpat
> >   - cross-gdb: always enable expat support
> >   - native-gdb: ditto
> 
> In other words, if the build doesn't interfere with gdb's ./configure,
> gdb's ./configure will naturally look for and link in the host's
> expat?

Almost, as we still need to tell the native-gdb's ./configure where to
find our internally built target expat/ncurses.

But for the cross-gdb, it should automatically find the host's libs,
indeed, so you still need to install the devel packages on your host.

Regards,
Yann E. MORIN.
Michael Powell - March 3, 2013, 3:53 p.m.
I am confused. Speaking as a crosstool / cross-gdb end-user, what does
this mean wanting to deploy code to and consequently debug code on
target?

On Sun, Mar 3, 2013 at 8:58 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Trevor, All,
>
> On Sunday 03 March 2013 Trevor Woerner wrote:
>> On Sun, Mar 3, 2013 at 9:02 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>> > This is wrong:
>> >   - 'do_expat' is used to detect whether the expat lib shall be downloaded
>> >     and extracted;
>> >   - 'do_expat' is then mis-used:
>> >     - it is never used to build expat for the host, but is used to decide
>> >       whether to enable/disable expat in the cross-gdb
>> >     - it is used to decide whether to build expat for the target, but is
>> >       always set when the native-gdb is selected, so the check is pointless.
>>
>> So if I understand you correctly, the only thing the build needs to
>> determine is if expat needs to be included in the sysroot?
>
> Sorta. Crosstool-NG only builds a static version of libexpat, and never
> installs it in the sysroot (ditto ncurses).
>
> So, we only need to know whether we need to build expat (ncurses) for the
> target, and point gdb's configure to the place we installed it.
>
> The reason for not installing expat/ncurses in the sysroot is that the
> libs are not part of the toolchain. They are only used for internal
> components, and should not be exposed in the sysroot, in case the user
> wants another version, or different compile flags, or a patched version.
>
> This is purely internal to crosstool-NG.
>
>> > What should be done is:
>> >   - rename 'do_expat' to 'need_expat' (ditto for 'do_ncurses')
>> >   - use 'need_expat' only to decide whether to download/extract libexpat
>> >   - cross-gdb: always enable expat support
>> >   - native-gdb: ditto
>>
>> In other words, if the build doesn't interfere with gdb's ./configure,
>> gdb's ./configure will naturally look for and link in the host's
>> expat?
>
> Almost, as we still need to tell the native-gdb's ./configure where to
> find our internally built target expat/ncurses.
>
> But for the cross-gdb, it should automatically find the host's libs,
> indeed, so you still need to install the devel packages on your host.
>
> 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.  |
> '------------------------------^-------^------------------^--------------------'
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - March 3, 2013, 4:13 p.m.
Michael, All,

Please, do *not* top-post. It makes it difficult to see what part of
the original message confuses you.

On Sunday 03 March 2013 Michael Powell wrote:
> On Sun, Mar 3, 2013 at 8:58 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > On Sunday 03 March 2013 Trevor Woerner wrote:
> >> On Sun, Mar 3, 2013 at 9:02 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> >> > This is wrong:
> >> >   - 'do_expat' is used to detect whether the expat lib shall be downloaded
> >> >     and extracted;
> >> >   - 'do_expat' is then mis-used:
> >> >     - it is never used to build expat for the host, but is used to decide
> >> >       whether to enable/disable expat in the cross-gdb
> >> >     - it is used to decide whether to build expat for the target, but is
> >> >       always set when the native-gdb is selected, so the check is pointless.
> >>
> >> So if I understand you correctly, the only thing the build needs to
> >> determine is if expat needs to be included in the sysroot?
> >
> > Sorta. Crosstool-NG only builds a static version of libexpat, and never
> > installs it in the sysroot (ditto ncurses).
> >
> > So, we only need to know whether we need to build expat (ncurses) for the
> > target, and point gdb's configure to the place we installed it.
> >
> > The reason for not installing expat/ncurses in the sysroot is that the
> > libs are not part of the toolchain. They are only used for internal
> > components, and should not be exposed in the sysroot, in case the user
> > wants another version, or different compile flags, or a patched version.
> >
> > This is purely internal to crosstool-NG.
> >
> >> > What should be done is:
> >> >   - rename 'do_expat' to 'need_expat' (ditto for 'do_ncurses')
> >> >   - use 'need_expat' only to decide whether to download/extract libexpat
> >> >   - cross-gdb: always enable expat support
> >> >   - native-gdb: ditto
> >>
> >> In other words, if the build doesn't interfere with gdb's ./configure,
> >> gdb's ./configure will naturally look for and link in the host's
> >> expat?
> >
> > Almost, as we still need to tell the native-gdb's ./configure where to
> > find our internally built target expat/ncurses.
> >
> > But for the cross-gdb, it should automatically find the host's libs,
> > indeed, so you still need to install the devel packages on your host.

> I am confused. Speaking as a crosstool / cross-gdb end-user, what does
> this mean wanting to deploy code to and consequently debug code on
> target?

Nothing at all from an end-user perspective: the cross-gdb and the
native-gdb will both have expat support.

The expat version built by crosstool-NG is not exposed in the sysroot
on purpose, as it's not part of the toolchain: it's only needed to be
able to build the native-gdb, so we build a static version that we
properly hide away by not installing it in the sysroot.

The same goes for ncurses.

If you need expat or ncurses for your apps, you'll have to compile them.

Regards,
Yann E. MORIN.

Patch

diff -r f89f8e6f8766 -r bfbfdaaea859 scripts/build/debug/300-gdb.sh
--- a/scripts/build/debug/300-gdb.sh	Mon Feb 25 21:19:31 2013 +0100
+++ b/scripts/build/debug/300-gdb.sh	Sat Mar 02 10:57:02 2013 -0500
@@ -16,6 +16,7 @@ 
 
     if [ "${CT_GDB_CROSS}" = y ]; then
         do_gdb=y
+        do_expat=y
     fi
 
     if [ "${CT_GDB_GDBSERVER}" = "y" ]; then