On Wed, Oct 25, 2017 at 11:24 PM, Jim Wilson <wil...@tuliptree.org> wrote: > We have no targets that emit SDB debug info by default. We dropped all > of the SVR3 Unix and embedded COFF targets a while ago. The only > targets that are still able to emit SDB debug info are cygwin, mingw, > and msdosdjgpp. > > I tried a cygwin build with sources modified to emit SDB by default, to > see if the support was still usable. I ran into multiple problems. > There is no SDB support for IMPORTED_DECL which was added in 2008. - > freorder-functions and -freorder-blocks-and-partition did not work and > had to be disabled. I hit a cgraph assert because sdbout.c uses > assemble_name on types, which fails if there is a function and type > with the same name. This also causes types to be added to the debug > info with prepended underscores which is wrong. I then ran into a > problem with the i386_pe_declare_function_type call from > i386_pe_file_end and gave up because I didn't see an easy workaround. > > It seems clear that the SDB support is no longer usable, and probably > hasn't been for a while. This support should just be removed. > > SDB is both a debug info format and an old Unix debugger. There were > some references to the debugger that I left in, changing to past tense, > as the comments are useful history to explain why the code was written > the was it was. Otherwise, I tried to eliminate all references to sdb > as a debug info format. > > This patch series was tested with a C only cross compiler build for all > modified embedded targets, a default languages build for power aix, > i686 cygwin, and x86_64 linux. I also did gdb testsuite runs for > cygwin and linux. There were no regressions. > > As a debug info maintainer, I can self approve some of this stuff, > would be would be good to get a review from one of the other global > reviewers, and/or target maintainers.
You have my approval for this. Can you add a blurb to gcc-8/changes.html, like "support for emitting SDB debug info has been removed" in the caveats section? Thanks, Richard. > Jim >
