gdb 7.4 and libexpat

gdb 7.4 and libexpat

[Andreas Oberritter]

Hi everybody,

in our rootfs, when debugging remotely with gdbserver on mips32el, gdb
7.4 fails to find symbol names for use in backtraces. gdb 7.3.1 works
well. One of my colleagues ran git bisect and discovered the culprit:

gdb git revision 22d678fdfdfc56ec75555f8f44ae5f0c4fc97e9a
http://sourceware.org/ml/gdb-patches/2011-11/msg00103.html

We haven't found out why this patch breaks symbol lookup. However, we
found three options to fix backtraces with version 7.4:

1.) Revert the changeset, possibly without understanding it fully.
2.) Enable expat in gdb, dragging libexpat into the image.
3.) Disable expat in gdb-cross, possibly losing functionality.

It seems that if one side is compiled with expat and the other is not,
then gdb and gdbserver now have problems communicating with each other.

Which way would you prefer?

Regards,
Andreas

Re: gdb 7.4 and libexpat

[Henning Heinold]

On Wed, Mar 14, 2012 at 02:49:19AM +0100, Andreas Oberritter wrote:
> Hi everybody,
> 
> in our rootfs, when debugging remotely with gdbserver on mips32el, gdb
> 7.4 fails to find symbol names for use in backtraces. gdb 7.3.1 works
> well. One of my colleagues ran git bisect and discovered the culprit:
> 
> gdb git revision 22d678fdfdfc56ec75555f8f44ae5f0c4fc97e9a
> http://sourceware.org/ml/gdb-patches/2011-11/msg00103.html
> 
> We haven't found out why this patch breaks symbol lookup. However, we
> found three options to fix backtraces with version 7.4:
> 
> 1.) Revert the changeset, possibly without understanding it fully.
> 2.) Enable expat in gdb, dragging libexpat into the image.
> 3.) Disable expat in gdb-cross, possibly losing functionality.
> 
> It seems that if one side is compiled with expat and the other is not,
> then gdb and gdbserver now have problems communicating with each other.
> 
> Which way would you prefer?
> 
> Regards,
> Andreas
> 

Hi,

option 2 is my favourite.

Bye Henning

Re: gdb 7.4 and libexpat

[Khem Raj]

On (14/03/12 09:35), Henning Heinold wrote:
> On Wed, Mar 14, 2012 at 02:49:19AM +0100, Andreas Oberritter wrote:
> > Hi everybody,
> > 
> > in our rootfs, when debugging remotely with gdbserver on mips32el, gdb
> > 7.4 fails to find symbol names for use in backtraces. gdb 7.3.1 works
> > well. One of my colleagues ran git bisect and discovered the culprit:
> > 
> > gdb git revision 22d678fdfdfc56ec75555f8f44ae5f0c4fc97e9a
> > http://sourceware.org/ml/gdb-patches/2011-11/msg00103.html
> > 
> > We haven't found out why this patch breaks symbol lookup. However, we
> > found three options to fix backtraces with version 7.4:
> > 
> > 1.) Revert the changeset, possibly without understanding it fully.
> > 2.) Enable expat in gdb, dragging libexpat into the image.
> > 3.) Disable expat in gdb-cross, possibly losing functionality.
> > 
> > It seems that if one side is compiled with expat and the other is not,
> > then gdb and gdbserver now have problems communicating with each other.
> > 
> > Which way would you prefer?
> > 
> > Regards,
> > Andreas
> > 
> 
> Hi,
> 
> option 2 is my favourite.

yes enable expat on both ends is better. having xml support
is good to have better debugging experience.

> 
> Bye Henning
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
-Khem

Re: gdb 7.4 and libexpat

[Denys Dmytriyenko]

On Mon, Apr 02, 2012 at 01:09:09PM -0700, Khem Raj wrote:
> On (14/03/12 09:35), Henning Heinold wrote:
> > On Wed, Mar 14, 2012 at 02:49:19AM +0100, Andreas Oberritter wrote:
> > Hi,
> > 
> > option 2 is my favourite.
> 
> yes enable expat on both ends is better.

...

> having xml support is good to have better debugging experience.

I was wondering if this statement was meant to be April 1st joke or 
something... :)

-- 
Denys