Brad pointed out that he habitually sets NO_FAST_ALLOC when compiling m5.debug because the way FastAlloc handles memory allocation tends to be tolerant of memory allocation errors (like reusing objects after they've been deleted), and he's run across other people's bugs simply by running with NO_FAST_ALLOC. I pointed out that he's abusing the purpose of a sticky config variable by toggling it based on which binary he's compiling, but he didn't seem to care ;-).
He has a good point though, so what I would like to do is condition the use of FastAlloc on whether DEBUG is set. While this sounds straightforward, there are several minor complications I want to solicit input on before I do this. (Though of course people are free to object with the basic premise if they choose.) - It seems like there should be a way to force FastAlloc to be on even for m5.debug, on the off chance you might want to debug FastAlloc itself, or if there's some other bug that presents itself more readily in combination with FastAlloc. I propose adding a FORCE_FAST_ALLOC sticky config var to do this. - There's some code protected by '#if FAST_ALLOC_DEBUG' that is intended to help debug memory leaks using FastAlloc. I've used it once or twice, but I kind of doubt that anyone else has, and I'm sure it's not as good as using valgrind or probably several other malloc debug packages. It seems particuarly ironic to have debug code in a module that is disabled in m5.debug, so I propose getting rid of this. That would also let us get rid of the FAST_ALLOC_DEBUG scons sticky var, so we'd be at a wash in terms of sticky var count. Any comments? Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
