Hi Tia,
On Wed, Aug 02, 2023 at 10:27:10AM -0500, Tia Newhall wrote:
> 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.
email is a little unreliable these days :{
And then I went on vacation. So apologies for the long delay.
> 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.
Sorry nobody commented on that bug. I have added a bit on debugging IR
blocks as a comment.
> 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?
I admit I have not used these interfaces ever. And as far as I can see
they were only used by the ptrcheck tool from 2008, renamed to sgcheck
in 2011, which was removed in 2020 (and hadn't really seen any updates
except for that name change).
While reviewing the lazy debuginfo loading patches from Aaron (now
integrated) I realized nothing was using these interfaces, so I didn't
really review whether they still worked correctly. Which is why I
proposed to remove them.
https://bugs.kde.org/show_bug.cgi?id=471807
https://bugs.kde.org/show_bug.cgi?id=472512
Since we don't have any code that uses StackBlock or GlobalBlock we
also don't have any tests. Without tests we don't know whether we
break something.
So if we are going to keep this functionality we really need some
tests.
Cheers,
Mark
> 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
