Re: Review Request 126309: backtrace and demangle for OS X, FreeBSD and Solaris/OpenIndiana
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126309/#review90392 --- This is kdelibs4support, this code is doomed to disappear and apps are using kDebug less and less. Is it worth risking compilation breakages on some systems? Also I found kBacktrace less and less useful over the years because with hidden visibility I get a lot of "???" for non-exported methods. gdb works much better. - David Faure On Dec. 10, 2015, 10:10 p.m., René J.V. Bertin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126309/ > --- > > (Updated Dec. 10, 2015, 10:10 p.m.) > > > Review request for KDE Software on Mac OS X and KDE Frameworks. > > > Repository: kdelibs4support > > > Description > --- > > This is a "backport" of the patches to `kdebug.cpp` that enable backtrace and > demangling support on OS X, FreeBSD and Solaris/OpenIndiana. > The KDE4 version was discussed here: https://git.reviewboard.kde.org/r/121213/ > > It seems that change was never incorporated because of a single open issue > for which I never found the time (also given that it seemed a bit overkill). > > My PC-BSD and Indiana VMs are no longer operational; it seems highly likely > that the current code still works but if further testing or polishing is > required I'll rather remove the specific parts than bring the VMs online > again. > > > Diffs > - > > src/kdecore/kdebug.cpp 6f04dce > > Diff: https://git.reviewboard.kde.org/r/126309/diff/ > > > Testing > --- > > On Kubuntu 14.04 with various gcc versions and clang; OS X 10.6 - 10.9 with > gcc and clang, PC-BSD with clang and on Open Indiana. > > The KDE4 RR raises some doubts concerning checking for only an OS and not > compilers (in demangling). I think there is no reason for such doubts: > compilers are obliged to co-exist and be compatible nowadays, at least on > individual OS families (each platform will have its own default/dominant > compiler that is used to build the system libraries). In practice it turns > out that gcc and clang use the same C++ mangling scheme. The only difference > is in the way `backtrace_symbols()` formats the stack, and that indeed > appears to defined the OS rather than by the compiler used. > (Then again I'm willing to stand corrected by someone who has a Linux system > built from scratch with clang and libc++, or possibly a Gnu/BSD set-up :)) > > > Thanks, > > René J.V. Bertin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126309: backtrace and demangle for OS X, FreeBSD and Solaris/OpenIndiana
> On Jan. 1, 2016, 4:04 p.m., David Faure wrote: > > This is kdelibs4support, this code is doomed to disappear and apps are > > using kDebug less and less. Is it worth risking compilation breakages on > > some systems? > > > > Also I found kBacktrace less and less useful over the years because with > > hidden visibility I get a lot of "???" for non-exported methods. gdb works > > much better. I'd hope that we can avoid the compilation breakages and have no idea of the timescale of planned obsolescence. I'm actually still getting pretty useful backtraces in KDE4 applications; I'd have to see how that works out for Qt5 apps (QtCurve uses kdelibs4support; I could use that to get kbacktraces from pretty "deep" places ;) ). So how does DrKonqi/KF5 work? Doesn't it use equivalent code if not built on kdelibs4support itself? - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126309/#review90392 --- On Dec. 10, 2015, 11:10 p.m., René J.V. Bertin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126309/ > --- > > (Updated Dec. 10, 2015, 11:10 p.m.) > > > Review request for KDE Software on Mac OS X and KDE Frameworks. > > > Repository: kdelibs4support > > > Description > --- > > This is a "backport" of the patches to `kdebug.cpp` that enable backtrace and > demangling support on OS X, FreeBSD and Solaris/OpenIndiana. > The KDE4 version was discussed here: https://git.reviewboard.kde.org/r/121213/ > > It seems that change was never incorporated because of a single open issue > for which I never found the time (also given that it seemed a bit overkill). > > My PC-BSD and Indiana VMs are no longer operational; it seems highly likely > that the current code still works but if further testing or polishing is > required I'll rather remove the specific parts than bring the VMs online > again. > > > Diffs > - > > src/kdecore/kdebug.cpp 6f04dce > > Diff: https://git.reviewboard.kde.org/r/126309/diff/ > > > Testing > --- > > On Kubuntu 14.04 with various gcc versions and clang; OS X 10.6 - 10.9 with > gcc and clang, PC-BSD with clang and on Open Indiana. > > The KDE4 RR raises some doubts concerning checking for only an OS and not > compilers (in demangling). I think there is no reason for such doubts: > compilers are obliged to co-exist and be compatible nowadays, at least on > individual OS families (each platform will have its own default/dominant > compiler that is used to build the system libraries). In practice it turns > out that gcc and clang use the same C++ mangling scheme. The only difference > is in the way `backtrace_symbols()` formats the stack, and that indeed > appears to defined the OS rather than by the compiler used. > (Then again I'm willing to stand corrected by someone who has a Linux system > built from scratch with clang and libc++, or possibly a Gnu/BSD set-up :)) > > > Thanks, > > René J.V. Bertin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126309: backtrace and demangle for OS X, FreeBSD and Solaris/OpenIndiana
> On Jan. 1, 2016, 3:04 p.m., David Faure wrote: > > This is kdelibs4support, this code is doomed to disappear and apps are > > using kDebug less and less. Is it worth risking compilation breakages on > > some systems? > > > > Also I found kBacktrace less and less useful over the years because with > > hidden visibility I get a lot of "???" for non-exported methods. gdb works > > much better. > > René J.V. Bertin wrote: > I'd hope that we can avoid the compilation breakages and have no idea of > the timescale of planned obsolescence. > > I'm actually still getting pretty useful backtraces in KDE4 applications; > I'd have to see how that works out for Qt5 apps (QtCurve uses > kdelibs4support; I could use that to get kbacktraces from pretty "deep" > places ;) ). > > So how does DrKonqi/KF5 work? Doesn't it use equivalent code if not built > on kdelibs4support itself? My problems where in kde4 apps. drkonqi attaches a debugger, it does not use a backtrace function. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126309/#review90392 --- On Dec. 10, 2015, 10:10 p.m., René J.V. Bertin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126309/ > --- > > (Updated Dec. 10, 2015, 10:10 p.m.) > > > Review request for KDE Software on Mac OS X and KDE Frameworks. > > > Repository: kdelibs4support > > > Description > --- > > This is a "backport" of the patches to `kdebug.cpp` that enable backtrace and > demangling support on OS X, FreeBSD and Solaris/OpenIndiana. > The KDE4 version was discussed here: https://git.reviewboard.kde.org/r/121213/ > > It seems that change was never incorporated because of a single open issue > for which I never found the time (also given that it seemed a bit overkill). > > My PC-BSD and Indiana VMs are no longer operational; it seems highly likely > that the current code still works but if further testing or polishing is > required I'll rather remove the specific parts than bring the VMs online > again. > > > Diffs > - > > src/kdecore/kdebug.cpp 6f04dce > > Diff: https://git.reviewboard.kde.org/r/126309/diff/ > > > Testing > --- > > On Kubuntu 14.04 with various gcc versions and clang; OS X 10.6 - 10.9 with > gcc and clang, PC-BSD with clang and on Open Indiana. > > The KDE4 RR raises some doubts concerning checking for only an OS and not > compilers (in demangling). I think there is no reason for such doubts: > compilers are obliged to co-exist and be compatible nowadays, at least on > individual OS families (each platform will have its own default/dominant > compiler that is used to build the system libraries). In practice it turns > out that gcc and clang use the same C++ mangling scheme. The only difference > is in the way `backtrace_symbols()` formats the stack, and that indeed > appears to defined the OS rather than by the compiler used. > (Then again I'm willing to stand corrected by someone who has a Linux system > built from scratch with clang and libc++, or possibly a Gnu/BSD set-up :)) > > > Thanks, > > René J.V. Bertin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126309: backtrace and demangle for OS X, FreeBSD and Solaris/OpenIndiana
> On Jan. 1, 2016, 4:04 p.m., David Faure wrote: > > This is kdelibs4support, this code is doomed to disappear and apps are > > using kDebug less and less. Is it worth risking compilation breakages on > > some systems? > > > > Also I found kBacktrace less and less useful over the years because with > > hidden visibility I get a lot of "???" for non-exported methods. gdb works > > much better. > > René J.V. Bertin wrote: > I'd hope that we can avoid the compilation breakages and have no idea of > the timescale of planned obsolescence. > > I'm actually still getting pretty useful backtraces in KDE4 applications; > I'd have to see how that works out for Qt5 apps (QtCurve uses > kdelibs4support; I could use that to get kbacktraces from pretty "deep" > places ;) ). > > So how does DrKonqi/KF5 work? Doesn't it use equivalent code if not built > on kdelibs4support itself? > > David Faure wrote: > My problems where in kde4 apps. > > drkonqi attaches a debugger, it does not use a backtrace function. Ah, hum, you're right. A debugger which doesn't always return control to drkonqi (when it's lldb), I knew that all too well ... - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126309/#review90392 --- On Dec. 10, 2015, 11:10 p.m., René J.V. Bertin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126309/ > --- > > (Updated Dec. 10, 2015, 11:10 p.m.) > > > Review request for KDE Software on Mac OS X and KDE Frameworks. > > > Repository: kdelibs4support > > > Description > --- > > This is a "backport" of the patches to `kdebug.cpp` that enable backtrace and > demangling support on OS X, FreeBSD and Solaris/OpenIndiana. > The KDE4 version was discussed here: https://git.reviewboard.kde.org/r/121213/ > > It seems that change was never incorporated because of a single open issue > for which I never found the time (also given that it seemed a bit overkill). > > My PC-BSD and Indiana VMs are no longer operational; it seems highly likely > that the current code still works but if further testing or polishing is > required I'll rather remove the specific parts than bring the VMs online > again. > > > Diffs > - > > src/kdecore/kdebug.cpp 6f04dce > > Diff: https://git.reviewboard.kde.org/r/126309/diff/ > > > Testing > --- > > On Kubuntu 14.04 with various gcc versions and clang; OS X 10.6 - 10.9 with > gcc and clang, PC-BSD with clang and on Open Indiana. > > The KDE4 RR raises some doubts concerning checking for only an OS and not > compilers (in demangling). I think there is no reason for such doubts: > compilers are obliged to co-exist and be compatible nowadays, at least on > individual OS families (each platform will have its own default/dominant > compiler that is used to build the system libraries). In practice it turns > out that gcc and clang use the same C++ mangling scheme. The only difference > is in the way `backtrace_symbols()` formats the stack, and that indeed > appears to defined the OS rather than by the compiler used. > (Then again I'm willing to stand corrected by someone who has a Linux system > built from scratch with clang and libc++, or possibly a Gnu/BSD set-up :)) > > > Thanks, > > René J.V. Bertin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 126309: backtrace and demangle for OS X, FreeBSD and Solaris/OpenIndiana
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126309/ --- Review request for KDE Software on Mac OS X and KDE Frameworks. Repository: kdelibs4support Description --- This is a "backport" of the patches to `kdebug.cpp` that enable backtrace and demangling support on OS X, FreeBSD and Solaris/OpenIndiana. The KDE4 version was discussed here: https://git.reviewboard.kde.org/r/121213/ It seems that change was never incorporated because of a single open issue for which I never found the time (also given that it seemed a bit overkill). My PC-BSD and Indiana VMs are no longer operational; it seems highly likely that the current code still works but if further testing or polishing is required I'll rather remove the specific parts than bring the VMs online again. Diffs - src/kdecore/kdebug.cpp 6f04dce Diff: https://git.reviewboard.kde.org/r/126309/diff/ Testing --- On Kubuntu 14.04 with various gcc versions and clang; OS X 10.6 - 10.9 with gcc and clang, PC-BSD with clang and on Open Indiana. The KDE4 RR raises some doubts concerning checking for only an OS and not compilers (in demangling). I think there is no reason for such doubts: compilers are obliged to co-exist and be compatible nowadays, at least on individual OS families (each platform will have its own default/dominant compiler that is used to build the system libraries). In practice it turns out that gcc and clang use the same C++ mangling scheme. The only difference is in the way `backtrace_symbols()` formats the stack, and that indeed appears to defined the OS rather than by the compiler used. (Then again I'm willing to stand corrected by someone who has a Linux system built from scratch with clang and libc++, or possibly a Gnu/BSD set-up :)) Thanks, René J.V. Bertin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
