|
From: William G. <app...@li...> - 2015-10-27 16:54:36
|
Hello, I would like to use some C++ containers in my tool. I have attempted to modify my tool's Makefile.am by adding AM_CXXFLAGS = -std=gnu++11 at the top and changing $(LINK) to $(CXXLINK). However, because of the -nodefaultlibs switch I have to manually add libraries to be linked. I receive a multiple definition error: /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/libc.a(abort.o): In function `abort': (.text+0x0): multiple definition of `abort' ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_main.o):/home/will/Downloads/vg1/coregrind/m_main.c:2861: first defined here There is a conflict because of valgrind's redefinition of standard library functions. Is it possible or are the examples of using C++ in a valgrind tool. Thanks, William |
|
From: Philippe W. <phi...@sk...> - 2015-10-28 21:36:11
|
On Tue, 2015-10-27 at 16:54 +0000, William Good wrote: > Hello, > I would like to use some C++ containers in my tool. I have attempted > to modify my tool's Makefile.am by adding AM_CXXFLAGS = -std=gnu++11 > at the top and changing $(LINK) to $(CXXLINK). However, because of > the -nodefaultlibs switch I have to manually add libraries to be > linked. I receive a multiple definition error: > > > /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/libc.a(abort.o): In function `abort': > (.text+0x0): multiple definition of `abort' > ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_main.o):/home/will/Downloads/vg1/coregrind/m_main.c:2861: first defined here > > > There is a conflict because of valgrind's redefinition of standard > library functions. Is it possible or are the examples of using C++ in > a valgrind tool. Using libraries to develop tool is not allowed. Even using the libc syscalls is not allowed, so valgrind has its own layer to interface to the kernel. Valgrind also has a re-implementation of all needed 'library functions' e.g. strcmp is not called in valgrind tools, instead, you need to call the re-implementation that has the name VG_(strcmp). As far as I know, the reason is that using libraries in a tool might give that some library functions would be re-entered (called by the tool) while a function of the library might be "busy" executing by the client. This can then lead to deadlocks or whatever similar problems (e.g. imagine the library has a lock. If the tool calls a function that needs to take the same lock, this will give a deadlock). In summary, you cannot use any library in Valgrind tools. I think you should be able to use C++, as long as your C++ code does not make any library calls/does not have any dependency to any c++ runtime/library/... So, using c++ without any runtime/library might be difficult to achieve. Philippe NB: I replied to the valgrind developer post. No need to ask such questions on the user list, the valdev list is the good one for such subjects. |
|
From: William G. <app...@li...> - 2015-10-29 01:10:57
|
Thank you for your response. If I would like to use an STL container to store data, would it be prudent to link with a custom library that replaces C library functions with VG(functions)? ________________________________________ From: Philippe Waroquiers <phi...@sk...> Sent: Wednesday, October 28, 2015 5:37 PM To: William Good Cc: val...@li... Subject: Re: [Valgrind-developers] Developing a tool using C++STL On Tue, 2015-10-27 at 16:54 +0000, William Good wrote: > Hello, > I would like to use some C++ containers in my tool. I have attempted > to modify my tool's Makefile.am by adding AM_CXXFLAGS = -std=gnu++11 > at the top and changing $(LINK) to $(CXXLINK). However, because of > the -nodefaultlibs switch I have to manually add libraries to be > linked. I receive a multiple definition error: > > > /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/libc.a(abort.o): In function `abort': > (.text+0x0): multiple definition of `abort' > ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_main.o):/home/will/Downloads/vg1/coregrind/m_main.c:2861: first defined here > > > There is a conflict because of valgrind's redefinition of standard > library functions. Is it possible or are the examples of using C++ in > a valgrind tool. Using libraries to develop tool is not allowed. Even using the libc syscalls is not allowed, so valgrind has its own layer to interface to the kernel. Valgrind also has a re-implementation of all needed 'library functions' e.g. strcmp is not called in valgrind tools, instead, you need to call the re-implementation that has the name VG_(strcmp). As far as I know, the reason is that using libraries in a tool might give that some library functions would be re-entered (called by the tool) while a function of the library might be "busy" executing by the client. This can then lead to deadlocks or whatever similar problems (e.g. imagine the library has a lock. If the tool calls a function that needs to take the same lock, this will give a deadlock). In summary, you cannot use any library in Valgrind tools. I think you should be able to use C++, as long as your C++ code does not make any library calls/does not have any dependency to any c++ runtime/library/... So, using c++ without any runtime/library might be difficult to achieve. Philippe NB: I replied to the valgrind developer post. No need to ask such questions on the user list, the valdev list is the good one for such subjects. |
|
From: Philippe W. <phi...@sk...> - 2015-11-02 21:53:03
|
On Thu, 2015-10-29 at 01:10 +0000, William Good wrote: > Thank you for your response. If I would like to use an STL container > to store data, would it be prudent to link with a custom library that > replaces C library functions with VG(functions)? The prudent way is to do the same as the other valgrind tools, i.e. use C and the existing valgrind containers/abstractions/... such as pub_tool_hashtable.h, pub_tool_oset.h, pub_tool_xarray.h, pub_tool_wordfm.h, .... Now, it might be possible to use C++ but I think you will encounter difficulties linked to the constraint 'no library'. I am not a C++ expert, but e.g. I guess that new/delete will not be usable, as these will be in a library and/or based on malloc/free. More generally, any C++ feature implemented fully or partially with a library will not be usable (including any c++ feature that imply doing a syscall). I think nobody tried to use C++ up to now to write a valgrind tool, so you will not be able to get much help on the valdev list. Finally, IMO, merging a new layer in coregrind of c++ containers similar to something that already exists (cfr above) makes the merge of the tool in the valgrind svn less likely. So, IMO, better stick with C (at least for a first trial of a tool). On the other hand, using c++ in valgrind is for sure a technically interesting challenge :) Philippe |
|
From: Patrick J. L. <lop...@gm...> - 2015-11-03 17:19:10
|
On Mon, Nov 2, 2015 at 1:54 PM, Philippe Waroquiers <phi...@sk...> wrote: > > The prudent way is to do the same as the other valgrind tools, > i.e. use C and the existing valgrind containers/abstractions/... > such as pub_tool_hashtable.h, pub_tool_oset.h, pub_tool_xarray.h, > pub_tool_wordfm.h, .... You are right, of course. But just in case someone is feeling imprudent... > Now, it might be possible to use C++ but I think you will encounter > difficulties linked to the constraint 'no library'. > I am not a C++ expert, but e.g. I guess that new/delete will not > be usable, as these will be in a library and/or based on malloc/free. > More generally, any C++ feature implemented fully or partially with > a library will not be usable (including any c++ feature that > imply doing a syscall). For the containers and algorithms in the C++ standard library, "new" and "delete" should be the only problem. (Note that I mean "container" and "algorithm" in the C++ standard sense; think vector, map, unordered_set, etc., plus anything from the <algorithm> header.) All standard C++ containers take an optional "allocator" template parameter, so it is possible to teach them to use whatever allocation and deallocation mechanism you want at compile time. It is not pretty -- indeed, it is a bit of a nightmare -- but it is both possible and fully standards-compliant. > So, IMO, better stick with C (at least for a first trial of a tool). Yes, that would surely be prudent. - Pat |
|
From: Greg P. <gp...@ap...> - 2015-11-04 00:23:11
|
> On Nov 3, 2015, at 9:19 AM, Patrick J. LoPresti <lop...@gm...> wrote: > > On Mon, Nov 2, 2015 at 1:54 PM, Philippe Waroquiers > <phi...@sk...> wrote: >> >> The prudent way is to do the same as the other valgrind tools, >> i.e. use C and the existing valgrind containers/abstractions/... >> such as pub_tool_hashtable.h, pub_tool_oset.h, pub_tool_xarray.h, >> pub_tool_wordfm.h, .... > > You are right, of course. But just in case someone is feeling imprudent... > >> Now, it might be possible to use C++ but I think you will encounter >> difficulties linked to the constraint 'no library'. >> I am not a C++ expert, but e.g. I guess that new/delete will not >> be usable, as these will be in a library and/or based on malloc/free. >> More generally, any C++ feature implemented fully or partially with >> a library will not be usable (including any c++ feature that >> imply doing a syscall). > > For the containers and algorithms in the C++ standard library, "new" > and "delete" should be the only problem. (Note that I mean "container" > and "algorithm" in the C++ standard sense; think vector, map, > unordered_set, etc., plus anything from the <algorithm> header.) There are other problems. STL containers sometimes call the runtime library to do their work. For example, LLVM's libc++ implementation has a function called __next_prime() which is used by the hash-based containers (unordered_map and others). That function is implemented in the libcxx runtime library and is never inlined. If you don't link to the libcxx runtime then you can't use those containers. -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: John R. <jr...@bi...> - 2015-11-04 16:07:32
|
>> For the containers and algorithms in the C++ standard library, "new" >> and "delete" should be the only problem. (Note that I mean "container" >> and "algorithm" in the C++ standard sense; think vector, map, >> unordered_set, etc., plus anything from the <algorithm> header.) > > There are other problems. STL containers sometimes call the runtime library to do their work. For example, LLVM's libc++ implementation has a function called __next_prime() which is used by the hash-based containers (unordered_map and others). That function is implemented in the libcxx runtime library and is never inlined. If you don't link to the libcxx runtime then you can't use those containers. Supplying replacement libraries is expected when dealing with "embedded" environments such as valgrind internals. Often only a few functions are needed, and often reduced functionality and/or loss of speed is acceptable. In the particular case of next_prime(unsigned n) used by hash tables, the following reduced requirements may be enough: a) x > n b) odd(x) c) 1 == gcd(x, n) [or, combining with b): 1 == gcd(x, 2*n)] d) 1 == gcd(x, 3*5*7*11*13*17*19*23*29u) e) 1 == gcd(x, 31*37*41*43*47u) 'x' will be correct for n < (53*53) and for most other cases, too. The bad effects of being composite might be only some slowness due to probing only part of the table. |
|
From: <pa...@fr...> - 2015-11-04 15:03:55
|
----- Original Message ----- > Hello, > I would like to use some C++ containers in my tool. I have attempted > to modify my tool's Makefile.am by adding AM_CXXFLAGS = -std=gnu++11 > at the top and changing $(LINK) to $(CXXLINK). However, because of > the -nodefaultlibs switch I have to manually add libraries to be > linked. I receive a multiple definition error: > > > /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/libc.a(abort.o): > In function `abort': > (.text+0x0): multiple definition of `abort' > ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_main.o):/home/will/Downloads/vg1/coregrind/m_main.c:2861: > first defined here > > > There is a conflict because of valgrind's redefinition of standard > library functions. Is it possible or are the examples of using C++ > in a valgrind tool. Hi Google Thread Sanitizer [https://code.google.com/p/data-race-test/wiki/ThreadSanitizer] advertises that it uses C++. This has been dead for some time (replaced with a GCC/llvm run time tool). I've only ever glanced at the tsan code, and I presume that all of the Valgrind interfaces are done in C and the post run analysis code is done in C++. A+ Paul |