summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/code_analysis/discussion.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/code_analysis/discussion.mdwn')
-rw-r--r--service_solahart_jakarta_selatan__082122541663/code_analysis/discussion.mdwn245
1 files changed, 245 insertions, 0 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/code_analysis/discussion.mdwn b/service_solahart_jakarta_selatan__082122541663/code_analysis/discussion.mdwn
new file mode 100644
index 00000000..45126b91
--- /dev/null
+++ b/service_solahart_jakarta_selatan__082122541663/code_analysis/discussion.mdwn
@@ -0,0 +1,245 @@
+[[!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]].