diff options
Diffstat (limited to 'open_issues/code_analysis')
| -rw-r--r-- | open_issues/code_analysis/discussion.mdwn | 245 |
1 files changed, 0 insertions, 245 deletions
diff --git a/open_issues/code_analysis/discussion.mdwn b/open_issues/code_analysis/discussion.mdwn deleted file mode 100644 index 45126b91..00000000 --- a/open_issues/code_analysis/discussion.mdwn +++ /dev/null @@ -1,245 +0,0 @@ -[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_documentation]] - -[[!toc]] - - -# IRC, freenode, #hurd, 2011-12-04 - - <mcsim> defpager uses it's own dynamic memory allocator, which uses - vm_allocate/vm_deallocate as backing store? Am I able to use duma in such - case? - <braunr> you will have to adapt it - <braunr> but it's already designed to handle custom allocators - <braunr> iirc - <braunr> btw, are there special flags for that memory which the pager - allocates ? - <braunr> e.g. to use wired memory ? - <mcsim> yes, wired memory - <braunr> you'll have to change that in duma then - <braunr> but apart from such details, it should be straightforward - - <antrik> braunr: I have no idea about duma; but if you think it's a useful - tool, please add it to open_issues/code_analysis.mdwn - <antrik> (I guess we should have a "proper" page listing useful debugging - tools...) - - -## IRC, freenode, #hurd, 2012-09-03 - - <mcsim> hello. Has anyone tried some memory debugging tools like duma or - dmalloc with hurd? - <braunr> mcsim: yes, but i couldn't - <braunr> i tried duma, and it crashes, probably because of cthreads :) - - -# Static Analysis - -## IRC, freenode, #hurd, 2012-09-08 - - <mcsim> hello. What static analyzer would you suggest (probably you have - tried it for hurd already)? - <braunr> mcsim: if you find some good free static analyzer, let me know :) - <pinotree> a simple one is cppcheck - <mcsim> braunr: I'm choosing now between splint and adlint - - -## IRC, freenode, #hurd, 2013-10-17 - - <teythoon> whoa, llvm kinda works, enough to make scan-build work :) - <braunr> teythoon: what is scan-build ? - <teythoon> braunr: clangs static analyzer - <braunr> ok - <teythoon> I'm doing a full build of the hurd using it, I will post the - report once it is finished - <teythoon> this will help spot many problems - <teythoon> well, here are the scan-build reports I got so far: - https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/ - <teythoon> I noticed it finds problems in mig generated code, so there are - probably lot's of duplictaes for those kind of problems - <pinotree> what's a... better one to look at? - <teythoon> it's also good at spotting error handling errors, and can spot - leaks sometimes - <teythoon> hm - <teythoon> - https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-yVBHO1.html - <braunr> that's minor, the device always exist - <braunr> but that's still ugly - <teythoon> - https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-MtgWSa.html - <teythoon> - https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-QdsZIm.html - <teythoon> this could be important: - https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-PDMEbk.html - <teythoon> this is the issue it finds in mig generated server stubs: - https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-iU3soc.html - <braunr> this one is #if TypeCheck1 - <braunr> the libports one looks weird indeed - <teythoon> but TypeCheck is 1 (the tooltip shows macro expansion) - <teythoon> it is defined in line 23 - <braunr> oh - <teythoon> hmmm... clang does not support nested functions, that will limit - its usefulness for us :/ - <braunr> yes - <braunr> one more reason not to use them - - -### IRC, freenode, #hurd, 2013-10-18 - - <teythoon> more complete, now with index: - https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build-2/ - - -### IRC, freenode, #hurd, 2013-11-04 - - <teythoon> btw, why does the nested functions stuff needs the executable - stack? for trampolines? - <braunr> yes - <teythoon> I didn't even realize that, that's one more reason to avoid them - indeed - - <teythoon> braunr: kern/slab.c (1471): vm_size_t info_size = info_size; - <braunr> yes ? - <teythoon> braunr: what's up with that? - <braunr> that's one way to silence gcc warnings about uninitialized - variables - <braunr> this warning can easily result in false positives when gcc is - unable to determine dependencies - <braunr> e.g. if (flag & FLAG_CREATE) myvar = create(); ...; ... if (flag & - FLAG_CREATE) use(myvar) - <teythoon> well, ok, that's a shortcomming of gcc - <teythoon> braunr: your way of silencing that in gcc still shows up in - scan-build and most likely any more advanced analysis tool - <teythoon> as it should of course, but it is noisy - <braunr> teythoon: there is a gcc attribute for that - <braunr> __attribute__((unused)) - <braunr> analysis tools might know that better - <teythoon> braunr: could you have a quick look at - http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-mXqstT.html#EndPath - ? - <braunr> nice - <braunr> anything else on the rbtree code ? - <teythoon> well - <teythoon> - http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-LyiOO1.html#EndPath - <teythoon> but this is of length 18, so it might be far-fetched - <braunr> ?? - <teythoon> the length of the chain of argumentation - <braunr> i don't understand that issue - <braunr> isn't 18 the analysis step ? - <teythoon> well, the greater the length, the more assumption the tool - makes, the more likely it is that it just does not "get" some invariant - <braunr> probably yes - <braunr> the code can segfault if input parameters are invalid - <braunr> that's expected - <teythoon> right, looks like this only happens if the tree is invalid - <teythoon> if in line 349 brother->children[right] is NULL - <teythoon> this is a very good target for verification using frama-c - <braunr> :) - <teythoon> the code already has many assertions that will be picked up by - it automatically - <teythoon> so what about the dead store, is it a bug or is it harmless ? - <braunr> harmless probably - <braunr> certainly - <braunr> a simple overlook when polishing - - -### IRC, freenode, #hurd, 2014-01-16 - - <mcsim> braunr: hi. Once, when I wrote a lot if inline gcc functions in - kernel you said me not to use them. And one of the arguments was that you - want to know which binary will be produced. Do you remember that? - <braunr> not exactly - <braunr> it seems likely that i advice not to use many inline functions - <braunr> but i don't see myself stating such a reason - <mcsim> braunr: ok - <mcsim> so, what do you think about using some high level primitives in - kernel - <mcsim> like inline-functions - <mcsim> ? - <braunr> "high level primitives" ? - <braunr> you mean switching big and important functions into inline code ? - <mcsim> braunr: something that is hard to translate in assembly directly - <mcsim> braunr: I mean in general - <braunr> i think it's bad habit - <mcsim> braunr: why? - <braunr> don't inline anything at first, then profile, then inline if - function calls really are a bottleneck - <mcsim> my argument would be that it makes code more readable - <braunr> https://www.kernel.org/doc/Documentation/CodingStyle <= see the - "inline disease" - <braunr> uh - <braunr> more readable ? - <braunr> the only difference is an inline keyword - <mcsim> sorry - <mcsim> i confused with functions that you declare inside functions - <mcsim> nested - <mcsim> forgot the word - <mcsim> sorry - <braunr> ah nested - <braunr> my main argument against nested functions is that they're not - standard and hard to support for non-gcc tools - <braunr> another argument was that it required an executable stack but - there is apparently a way to reliably make nested functions without this - requirement - <braunr> so, at the language level, they bring nice closures - <braunr> the problem for me is at the machine level - <braunr> i don't know them well so i'm unable to predict the kind of code - they generate - <braunr> but i guess anyone who would take the time to study their - internals would be able to do that - <mcsim> and why this last argument is important? - <braunr> because machine code runs on machines - <braunr> one shouldn't ignore the end result .. - <braunr> if you don't know the implications of what you're doing precisely, - you loose control over the result - <braunr> if you can trust the tool, fine - <kilobug> mcsim: in general, when you use something you don't really - understand how it works internally, you've a much higher risk of making - bugs or inefficient code because you just didn't realize it couldn't work - or would be inefficient - <braunr> but in the case of a kernel, it often happens that you can't, or - at least not in a straightforward way - <braunr> s/loose/lose/ - <mcsim> kilobug: and that's why for kernel programming you try to use the - most straightforward primitives as possible? - <braunr> no - <kilobug> mcsim: not necessarily the most straightforward ones, but ones - you understand well - <braunr> keeping things simple is a way to keep control complexity in any - software - <braunr> as long as you understand, and decouple complicated things apart, - you can keep things simple - <braunr> nested functions doesn't have to do with complexity - <braunr> don't* - <braunr> it's just that, since they're not standard and commonly used - outside gnu projects, they're not well known - <braunr> i don't "master" them - <teythoon> also, they decouple the data flow from the control flow - <teythoon> which in my book is bad for imparative languages - <teythoon> and support for them in tools like gdb is poor - <mcsim> braunr: I remembered nested functions because now I use C++ and I - question myself if I may use all these C++ facilities, like lambdas, - complicated templates and other stuff. - <mcsim> kilobug: And using only things that you understand well sounds - straightforward and logical - <braunr> that's why i don't write c++ code :) - <braunr> it's very complicated and requires a lot of effort for the - developer to actually master it - <braunr> mcsim: you can use those features, but sparsely, when they really - do bring something useful - - -# Leak Detection - -See *Leak Detection* on [[boehm_gc]]. |