Re: GSoC Project Ideas
On Monday, 4 March, 2019, 4:37:07 AM IST, Patrick Palka wrote: >I am very interested in working on GCC as part of GSoC this year. >A few years ago I was a somewhat active code contributor[1] and >unfortunately my contributing waned once I went back to school, >but I'm excited to potentially have the opportunity to work on GCC again this >summer. > > * Extend VRP to track unions of intervals > (inspired by comment #2 of PR72443 [2]) > > * Make TREE_NO_WARNING more fine-grained > (inspired by comment #7 of PR74762 [3]) > > * Make -Wmaybe-uninitialized more robust > (Inspired by the recent thread to move -Wmaybe-uninitialized to -Wextra >[4]) > > * Bug fixing in the C++ frontend / general C++ frontend improvements > There are 100s of open PRs about the C++ frontend, and the goal here > would just be to resolve as many as one can over the summer. Interesting! >Would any of these ideas work as a GSoC project? -> https://gcc.gnu.org/ml/gcc/2019-03/msg00016.html -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 Could this RFE be considered for a GSoC project? Thank you. --- -P J P http://feedmug.com
Re: About BZ#87210 [RFE] To initialize automatic stack variables
On Tuesday, 19 February, 2019, 3:55:35 PM IST, P J P wrote: > >Hello, > > -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 > >This RFE is about providing gcc option(s) to eliminate information leakage >issues from programs. Information leakage via uninitialised memory has been >a chronic/recurring issue across all software. They are found quite often >and may lead to severe effects if found in system software/kernel, OR an >application which handles sensitive information. > >Various projects/efforts are underway to keep such information exposure >from happening > >* STACKLEAK - http://lkml.iu.edu/hypermail/linux/kernel/1810.3/00522.html >* KLEAK - https://netbsd.org/gallery/presentations/maxv/kleak.pdf >* https://j00ru.vexillium.org/papers/2018/bochspwn_reloaded.pdf > >But these are still external corrections to improve specific project and/or >software. It does not help to fix/eliminate all information leakage issues. >Automatic memory initialisation: > >* https://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html >* https://reviews.llvm.org/D54604 > >It'd be immensely helpful and welcome if gcc(1) could provide compile/build >time options to enable/disable - automatic memory initialisation. > >Could we please consider it as more viable/useful option? Ping...! --- -P J P http://feedmug.com
About BZ#87210 [RFE] To initialize automatic stack variables
Hello, -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210 This RFE is about providing gcc option(s) to eliminate information leakage issues from programs. Information leakage via uninitialised memory has beena chronic/recurring issue across all software. They are found quite often andmay lead to severe effects if found in system software/kernel, OR an applicationwhich handles sensitive information. Various projects/efforts are underway to keep such information exposurefrom happening * STACKLEAK - http://lkml.iu.edu/hypermail/linux/kernel/1810.3/00522.html * KLEAK - https://netbsd.org/gallery/presentations/maxv/kleak.pdf* https://j00ru.vexillium.org/papers/2018/bochspwn_reloaded.pdf But these are still external corrections to improve specific project and/orsoftware. It does not help to fix/eliminate all information leakage issues. Automatic memory initialisation: * https://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html * https://reviews.llvm.org/D54604 It'd be immensely helpful and welcome if gcc(1) could provide compile/buildtime options to enable/disable - automatic memory initialisation. Could we please consider it as more viable/useful option? Thank you.--- -P J P http://feedmug.com
DW_AT_external bug 45153 - patch
Hi, please have a look at the Bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153 And a patch(for gcc-4.4.4) posted therein. It seems to fix the issue. Yet, I need to confirm whether DW_AT_external flag should be set for the public functions of a C++ class or not? I guess not, because though public, such functions are not accessible without a class object, unlike regular non-member functions. I'd appreciate your insights about the same. Thank you. --- Regards -P J P PS: Please don't send me html/attachment/Fwd mails
DWARF DW_AT_external
Hi, As I understand, the DWARF tag DW_AT_external is meant to indicate whether a variable/function is accessible from outside the compilation unit(object file) containing the given DWARF DIE - Debugging Information Entry. But it looks like DW_AT_external is also set for variables/functions defined in a different object file, but has a DIE because of linking. See: http://pastebin.com/vFiBWuhh It has a small C++ program - greeting.cpp, with it's output and some DWARF information. As can be seen, the external flag is set for the standard library functions such as - swscanf, ungetwd, or vfwprintf - which are not defined or used in greeting.cpp, but are part of the object file because of linking. This makes it *difficult* to locate the DIEs describing the functions that are defined and used in greeting.cpp. Thank you. --- Regards -Prasad PS: Please don't send me html/attachment/Fwd mails
