gdb 7.4 and libexpat
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
Quoted 16 lines · 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.htmlWe 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.
Quoted 8 lines
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
Quoted 22 lines · Henning Heinold
Quoted 21 lines · 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.htmlWe 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?
Quoted 7 lines
Quoted 3 lines
Regards,
AndreasHi,
option 2 is my favourite.
yes enable expat on both ends is better. having xml support is good to have better debugging experience.
Quoted 7 lines
Bye Henning
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 1 line
-Khem
Quoted 7 lines · Khem Raj
Quoted 4 lines · Henning Heinold
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.
...
Quoted 1 line
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... :)
Signature · 1 line
Denys