| Summary: | Add a valgrind.h macro VALGRIND_REPLACES_MALLOC | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Paul Floyd <pjfloyd> |
| Component: | general | Assignee: | Paul Floyd <pjfloyd> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | philippe.waroquiers |
| Priority: | NOR | ||
| Version First Reported In: | 3.27 GIT | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Paul Floyd
2026-01-08 19:04:02 UTC
Circular reference: https://github.com/gperftools/gperftools/issues/1167#issuecomment-3724870733 A maybe more general alternative to a macro 'VALGRIND_REPLACES_MALLOC" would be to provide to the guest a way to interrogate which tool is currently running. Then the guest can from the tool derive the fact that MALLOC is replaced but can also do other things differently depending on the tool. For example, when running under helgrind, at work, we have here and there some specific logic. Or yet another more extensible alternative: a "general" macro VALGRIND_GET_PROPERTY that would have an argument property_id with some constants defined in valgrind.h such as: TOOL (to get the name of the tool), REPLACES_MALLOC (returning if the current tool is replacing malloc); etc. I did think of something like getting the tool name. When I poked around I saw VG_(needs) which has malloc_replacement which is just right for this. All tools that replace malloc (even any 3rd party tools have to use this. Other than the tool name and malloc replacement are there any other attributes that you can think of that would be useful? (In reply to Paul Floyd from comment #3) > I did think of something like getting the tool name. When I poked around I > saw VG_(needs) which has malloc_replacement which is just right for this. > All tools that replace malloc (even any 3rd party tools have to use this. > > Other than the tool name and malloc replacement are there any other > attributes that you can think of that would be useful? Tool name and malloc replacement looks like the two most useful candidates. Possibly there might be an interest to allow the guest to query the value of a command line parameter or possibly there are some tool depending things that the guest might use. But that is just a brainstorming discussion. If all this introduces additional complexity, we better focus on the two things clearly identified. (In reply to Philippe Waroquiers from comment #4) > Tool name and malloc replacement looks like the two most useful candidates. > Possibly there might be an interest to allow the guest to query the value of > a command line parameter > or possibly there are some tool depending things that the guest might use. > > But that is just a brainstorming discussion. If all this introduces > additional complexity, > we better focus on the two things clearly identified. Getting the tool name will be a little bit complicated. I assume that we don't want to return a pointer to host memory to the guest. That means that this will have to use an interface like GET_VBITS, taking a pointer to a client array and length and returning 0 if not running on Valgrind or the actual length (so that the client code can check that the length that they provided is large enough). |