Hi Sebastian, Thanks for showing us this patch, and clarifying that it's solving a problem with using sparc-gdb! How should we test it?
To verify we didn't break anything, should we just follow http://gcc.gnu.org/simtest-howto.html ? >From the referenced email, I gather we could verify the debugging symbols >didn't work without the patch in gdb-7.6 and did work with the patch in >gdb-7.6. I'm just wanting some clarity on the procedure, so we can document it in the git://git.rtems.org/rtems-tools.git Thanks, Cindy >On 06/18/2013 02:10 PM, Ralf Corsepius wrote: >> On 06/18/2013 01:58 PM, 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 opposed to this patch, because >> >> * GNU software should not care about the limitations of commerical stuff and >> should only care about gdb. > >Actually GCC cares about commercial stuff, e.g. the VxWorks and Darwin ports >use exactly the same mechanism. > >The SPARC version of GDB seems to have problems here also: > >http://www.rtems.org/pipermail/rtems-devel/2013-May/003188.html > >> >> * We should stay with the GCC's defaults and not diverge from these. > >In general this is true. > >> * Users, who are facing issues with commerical stuff can always manually pass >> appropriate options to CC if they need it. > >This approach is not possible for the multilibs. _______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
