|
From: Bosso C. <C....@da...> - 2008-05-16 12:08:58
|
Hi I have to write a simple dissertation about Valgrind and I have read in the faq that it doesn't do bounds checking on static or stack arrays because is not possible in a reasonable way that fits with how Memcheck works. But why is not possible ? Somebody can explain what thwart the check ? Thank you ! |
|
From: dizzy <di...@ro...> - 2008-05-16 12:59:07
|
On Friday 16 May 2008 15:08:50 Bosso Claudio wrote: > Hi > > I have to write a simple dissertation about Valgrind and I have read in > the faq that it doesn't do bounds checking on static or stack arrays > because is not possible in a reasonable way that fits with how Memcheck > works. > > But why is not possible ? Somebody can explain what thwart the check ? Because you need language/compiler support for that. How do you know from a CPU emulator perspective (what valgrind is) what is an array on the stack and what size it was suposed to have? How do you know from that perspective that you are overflowing the array (in cases where the memory written by the overflow is valid, it belongs to another stack variable)? It probably can be done if you use some kind of valgrind macros in your code, to give valgrind the info it does not have (like this is an array of char of this size). -- Mihai RUSU Email: di...@ro... "Linux is obsolete" -- AST |
|
From: Bosso C. <C....@da...> - 2008-05-16 14:28:02
|
Thank you very much for the answer. Therefore, if I understand, Valgrind can check the boundary of dynamic memory because it's allocated at run-time and Memcheck/CPU Emulator can manage it, but can't check static array because it's allocated at compile time and the CPU emulator can't know it's size. It's right ? -----Messaggio originale----- Da: val...@li... [mailto:val...@li...] Per conto di dizzy Inviato: venerdì 16 maggio 2008 14:58 A: val...@li... Oggetto: Re: [Valgrind-users] Valgrind and Static Array On Friday 16 May 2008 15:08:50 Bosso Claudio wrote: > Hi > > I have to write a simple dissertation about Valgrind and I have read in > the faq that it doesn't do bounds checking on static or stack arrays > because is not possible in a reasonable way that fits with how Memcheck > works. > > But why is not possible ? Somebody can explain what thwart the check ? Because you need language/compiler support for that. How do you know from a CPU emulator perspective (what valgrind is) what is an array on the stack and what size it was suposed to have? How do you know from that perspective that you are overflowing the array (in cases where the memory written by the overflow is valid, it belongs to another stack variable)? It probably can be done if you use some kind of valgrind macros in your code, to give valgrind the info it does not have (like this is an array of char of this size). -- Mihai RUSU Email: di...@ro... "Linux is obsolete" -- AST ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: dizzy <di...@ro...> - 2008-05-16 15:12:55
|
On Friday 16 May 2008 17:27:52 Bosso Claudio wrote: > Thank you very much for the answer. > > Therefore, if I understand, Valgrind can check the boundary of dynamic > memory because it's allocated at run-time and Memcheck/CPU Emulator can > manage it, but can't check static array because it's allocated at compile > time and the CPU emulator can't know it's size. > > It's right ? I may have oversimplified valgrind's logic, it's like a CPU emulator combined with a syscall catcher and library calls catcher. It easily knows dynamic memory is valid because it catches malloc/free & co calls (so it can hold a table/state of these allocations and check against them). For stack arrays however, what happens is that the compiler (at compile time of course) just figures out that inside a function how much bytes it needs to substract from the stack pointer (how much memory it needs in total on the stack in that function, including padding and such) and it will have a CPU instruction that "allocates" all that memory at once, it does not create separate/special code for each auto variable (thus valgrind cannot know what variables do you have on stack, their size, types, etc). This is why bounds checking memory debuggers usually worked with a patch over the compiler (as it needs compiler support). I wonder if there is support to describe variables on stack by enabling various debugging levels (I might be talking BS here). -- Mihai RUSU Email: di...@ro... "Linux is obsolete" -- AST |
|
From: Bosso C. <C....@da...> - 2008-05-16 16:32:23
|
Thanks very much, Now I resolve my doubts ! Bye Claudio -----Messaggio originale----- Da: val...@li... [mailto:val...@li...] Per conto di dizzy Inviato: venerdì 16 maggio 2008 17:11 A: val...@li... Oggetto: Re: [Valgrind-users] R: Valgrind and Static Array On Friday 16 May 2008 17:27:52 Bosso Claudio wrote: > Thank you very much for the answer. > > Therefore, if I understand, Valgrind can check the boundary of dynamic > memory because it's allocated at run-time and Memcheck/CPU Emulator can > manage it, but can't check static array because it's allocated at compile > time and the CPU emulator can't know it's size. > > It's right ? I may have oversimplified valgrind's logic, it's like a CPU emulator combined with a syscall catcher and library calls catcher. It easily knows dynamic memory is valid because it catches malloc/free & co calls (so it can hold a table/state of these allocations and check against them). For stack arrays however, what happens is that the compiler (at compile time of course) just figures out that inside a function how much bytes it needs to substract from the stack pointer (how much memory it needs in total on the stack in that function, including padding and such) and it will have a CPU instruction that "allocates" all that memory at once, it does not create separate/special code for each auto variable (thus valgrind cannot know what variables do you have on stack, their size, types, etc). This is why bounds checking memory debuggers usually worked with a patch over the compiler (as it needs compiler support). I wonder if there is support to describe variables on stack by enabling various debugging levels (I might be talking BS here). -- Mihai RUSU Email: di...@ro... "Linux is obsolete" -- AST ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |