|
From: Potter, B. <Bra...@my...> - 2011-06-13 20:02:36
|
Hello VG_(developers), I am attempting to implement multi-core cache simulation under Valgrind. I have run into a few problems and I wanted to know if there was a way to match the /proc/self/maps (Valgrind) file onto the /proc/pid/maps file of a natively executing process. I want to map the information from the Valgrind simulation onto an actual run. I have looked at the address space manager within Coregrind and I am forcing the core to emit the debug information from the manager. I run into trouble when I try to compare the two. The Valgrind output does not seem to retain the [stack], [heap], [syscall], etc. identifiers. Furthermore, I have no way of correlating the anonymous regions. Ideally, I would like to identify the virtual addresses between the two on a 1:1 mapping. I realized that it would be possible to modify the Linux kernel to enumerate the individual listings, but that's not portable. Does anyone have an idea about how to approach this problem? I really don't want to modify a kernel module. It would be best if I could make the Valgrind client's map look exactly like one from normal execution. Thanks, Brandon Potter |
|
From: Bjoern D. <bjo...@go...> - 2011-06-13 20:42:55
|
Could it be that you're running into problems with address space layout randomization (ASLR) here? The Linux kernel has it turned on and that means that every time you run a program, its memory layout will differ. If so, you might try turning it off for your use case, see http://superuser.com/questions/127238/how-to-turn-off-aslr-in-ubuntu-9-10 . Then the layouts should only differ in the mappings Valgrind makes for its own use. Hth, Bjoern 2011/6/13 Potter, Brandon <Bra...@my...>: > Hello VG_(developers), > I am attempting to implement multi-core cache simulation under Valgrind. I > have run into a few problems and I wanted to know if there was a way to > match the /proc/self/maps (Valgrind) file onto the /proc/pid/maps file of a > natively executing process. I want to map the information from the Valgrind > simulation onto an actual run. > > I have looked at the address space manager within Coregrind and I am forcing > the core to emit the debug information from the manager. I run into trouble > when I try to compare the two. The Valgrind output does not seem to retain > the [stack], [heap], [syscall], etc. identifiers. Furthermore, I have no > way of correlating the anonymous regions. Ideally, I would like to identify > the virtual addresses between the two on a 1:1 mapping. I realized that it > would be possible to modify the Linux kernel to enumerate the individual > listings, but that's not portable. > Does anyone have an idea about how to approach this problem? I really don't > want to modify a kernel module. It would be best if I could make the > Valgrind client's map look exactly like one from normal execution. > > Thanks, > Brandon Potter > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > |
|
From: Potter, B. <Bra...@my...> - 2011-06-13 21:56:22
|
Hey Bjoern, Thanks for responding. ASLR is enabled on my computer; the virtual addresses change in the maps file, but I want a more general solution than disabling ASLR. It might help in the short term as far as comparing the mapping, but I would like to know if there is a way to ensure a 1:1 mapping by looking at something other than the virtual address. My thoughts revolved around enumerating the entries in the maps file as the kernel reserves space for them. The enumerations would be chronological and deterministic (I think). Valgrind would enumerate only the client stack in the same manner. The enumeration would act as a key into both maps files. With the virtual-virtual mapping done, I can associate the simulation's virtual address with the physical address as it would have run natively; I already have the virtual-physical translation done. Does anyone know if this is possible to achieve with the Valgrind framework? I've looked at the aspacemgr-linux.c file, but I don't know where to start. If anyone has any pointers or any pitfalls that I might encounter while trying this (or any of the other multi-core stuff), please let me know. -Brandon ________________________________________ From: Bjoern Doebel [bjo...@go...] Sent: Monday, June 13, 2011 1:42 PM To: Potter, Brandon Cc: val...@li... Subject: Re: [Valgrind-developers] Implementing A Multi-Core Cache Simulator Could it be that you're running into problems with address space layout randomization (ASLR) here? The Linux kernel has it turned on and that means that every time you run a program, its memory layout will differ. If so, you might try turning it off for your use case, see http://superuser.com/questions/127238/how-to-turn-off-aslr-in-ubuntu-9-10 . Then the layouts should only differ in the mappings Valgrind makes for its own use. Hth, Bjoern 2011/6/13 Potter, Brandon <Bra...@my...>: > Hello VG_(developers), > I am attempting to implement multi-core cache simulation under Valgrind. I > have run into a few problems and I wanted to know if there was a way to > match the /proc/self/maps (Valgrind) file onto the /proc/pid/maps file of a > natively executing process. I want to map the information from the Valgrind > simulation onto an actual run. > > I have looked at the address space manager within Coregrind and I am forcing > the core to emit the debug information from the manager. I run into trouble > when I try to compare the two. The Valgrind output does not seem to retain > the [stack], [heap], [syscall], etc. identifiers. Furthermore, I have no > way of correlating the anonymous regions. Ideally, I would like to identify > the virtual addresses between the two on a 1:1 mapping. I realized that it > would be possible to modify the Linux kernel to enumerate the individual > listings, but that's not portable. > Does anyone have an idea about how to approach this problem? I really don't > want to modify a kernel module. It would be best if I could make the > Valgrind client's map look exactly like one from normal execution. > > Thanks, > Brandon Potter > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > |