hi Mark, Thanks for you reply!
First, sorry but I'm cutting and pasting below your response from off the list archive below since I didn't receive an email with your reply. As far as your question about the tool I'm building...I'm building a C code tracing tool for educational purposes, and using valgrind as the backend of this tool. The resulting tool will be similar to Python tutor but with some differences. We also have an assembly code tracing tool that uses valgrind as the backend that we are close to completing. It doesn't work for ARM due to what I think is a vex bug in the ARM version ( https://bugs.kde.org/show_bug.cgi?id=460951), but it works for x86 architectures. The StackBlock and GlobalBlock structs and the interface for getting these are very useful for the tool I'm building. I really like the interfaces you were about to remove, but I'd like to add an TyEnt * entry to StackBlock and GlobalBlock to get detailed type information so that I can interpret and print out bytes of variables, and the memory they point to in some cases, in terms of the variable's specific C type. I believe the TyEnt has all the information I would need, but perhaps I am mistaken. What are your thoughts? Thanks, Tia Hi Tia, On Tue, 2023-08-01 at 08:56 -0500, Tia Newhall wrote: > I'm building a valgrind tool, and as part of its functionality I need to get (and ultimately print out) local and global variable values based on their C types. However, I do not see a way to get detailed type information for locals and globals via the tool public interface. > > The stack and global structs exported via VG_(di_get_global_blocks_from_dihandle) and VG_(di_get_stack_blocks_at_ip) give me back structs that include the variable name, the address, total size in bytes, and if it is an array or not, but this is not sufficient for my purposes. For example, if the variable is an array of 16 bytes I have no idea if it is an array of char, short, int, unsigned int, int *, etc., and if it is a struct or union I have no idea where the field types are, their names, nor their offsets and sizes from the base address, and if it is an array of structs or unions I have no idea if there is padding between elements or not, and enum and typedefs I'd just be out of luck. Even for non-array base types, I don't know if the value is signed or unsigned (ex. if 1 byte variable's value is 0xa1 is it -95 (char) or 161 (unsigned char)), and for Word sized values it could be a pointer or not, in which case I would want to display a pointer's value in hex, but if it is a long long I'd want to display it as a signed decimal. > > Since code in coregrind/m_debuginfo/ is parsing .debug to get the correct and detailed type information, offset, sizes, field names, etc., I'd like to get that info from coregrind for globals and locals through the public tool interface: it looks like the TyEnt struct has what I need. Good you write about this, because I was just about to commit the proposed patch from https://bugs.kde.org/show_bug.cgi?id=472512 "Remove Stack and Global Blocks from debuginfo handling" The VG_(di_get_stack_blocks_at_ip) and VG_(di_get_global_blocks_from_dihandle) functions were only used by the exp-sgcheck tool. Since this tool was removed a couple of years back this code hasn't been used or tested. Lets remove it to reduce the complexity of dealing with debuginfo. This code confused me till I realized it isn't actually used (and was last changed in 2008). So I think it is best to just remove it so it doesn't confuse others. But... now it seems you do want to use it. > First, is there a tool interface to this detailed type information about variables that I am missing (like info in TyEnt structs) and if so, can someone please point me to it? > > If not (and I think this is the case), I would have to add something new to the public tool interface to get the information I need, adding or modifying code in coregrind/m_debuginfo/ to do it. I can build my own custom version of valgrind with the functionality I need, but this is obviously not ideal for keeping up with new version releases. > > Is there developer interest in expanding the valgrind public tool interface to export the kind of detailed type information that I need for my tool? If so, I'd be happy to discuss with someone the best way to design and implement it and help work on its implementation. I think you would have to create a new interface. Unless you believe the current one is still useful. What does your tool do precisely? Cheers, Mark
_______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
