On Wed, Jun 19, 2013 at 3:22 AM, Sebastian Huber <[email protected]> wrote: > On 06/19/2013 01:54 AM, Chris Johns wrote: >> >> Sebastian Huber wrote: >>> >>> Some debuggers do not cope with the new DWARF3/4 debug format introduced >>> with GCC 4.8. Default to strict DWARF-2 on ARM, PowerPC and SPARC for >>> now. >>> >>> This patch should be committed to GCC 4.8 and 4.9. >>> >> >> I am not convinced about this change on technical grounds. When I say I am >> not >> convinced, I am not sure what we gain and what we give up and I would like >> to >> understand that a little better before agreeing to it. >> >> I should also point out I am using ARM with gcc-4.8.1 and gdb-7.6 and it >> is >> working well (my OpenOCD changes need more work) and any change to DWARF2 >> that >> alters this would be a regression. > > > The recent ARM GDB seems to have no problem with the new debug format. I > didn't see a differences in the debug experience between an old (e.g. 4.6.4) > and a newer (e.g. 4.8.1) GCC. I didn't debug C++. > > >> I have taken a look at the differences between DWARF2, DWARF3 and DWARF4. >> There >> is better language support in the later versions and debug data >> compression. >> These improvements are nice. What I am not sure about is the way limiting >> gcc >> to DWARF2 effects the debugging experience. If the flag is just a format >> change >> and the experience is the same that is ok, if however the C++ or C >> debugging >> experience is reduced that would be a regression. > > > Yes, but I didn't see a difference so far. Debugging optimized code is > still a pain. > > >> My major concern is locking us into this and it being forgotten and we sit >> on >> DWARF2 for ages and we do not see or notice regressions related to >> DWARF3/4 >> when it breaks on these archs. Can ARM/PowerPC/SPARC tools be built with a >> target option that limits the target libraries to DWARF2 ? > > > A compromise would be to apply this only to GCC 4.8. On PowerPC we have the > situation that GCC 4.8 is the first version after 4.3 with all known bugs > (bugs the render GCC useless and have no suitable workaround) fixed and no > new ones (to our knowledge). It will take some time to upgrade the debug > tools in running projects. > I'm fine with this compromise. If we apply it to gcc's development head then we need to review the change periodically to determine if DWARF 3/4 is ready to adopt for these couple of targets.
> >> >> Did a gdb bug get raised about the DWARF read error reported on the >> mailing list ? > > > No, I had no time to investigate this further. > > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : [email protected] > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > _______________________________________________ > rtems-devel mailing list > [email protected] > http://www.rtems.org/mailman/listinfo/rtems-devel _______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
