|
From: Anne D. <an...@ma...> - 2003-07-08 16:59:33
|
Very very small point but could be important for someone new to Valgrind -- I had to do some hunting to figure out how to change my personalized IOCTLs from 1.0.x. (I use Valgrind on click, which is custom packet handling software with a Linux kernel-loadable module that defines several of its own IOCTLs.) "README_MISSING_SYSCALL_OR_IOCTL" still talks about calling "must_be_readable" and "must_be_writable". It looks like these should be changed to SYSCALL_TRACK(pre_mem_read, ...) and SYSCALL_TRACK(pre_mem_write, ...). One question: What's the difference between 'pre_mem_read' and 'pre_mem_read_asciiz'? -Anne |
|
From: Nicholas N. <nj...@ca...> - 2003-07-21 08:13:26
|
On Tue, 8 Jul 2003, Anne Dudfield wrote: > Very very small point but could be important for someone new to > Valgrind -- I had to do some hunting to figure out how to change my > personalized IOCTLs from 1.0.x. (I use Valgrind on click, which is > custom packet handling software with a Linux kernel-loadable module > that defines several of its own IOCTLs.) > > "README_MISSING_SYSCALL_OR_IOCTL" still talks about calling > "must_be_readable" and "must_be_writable". It looks like these should > be changed to SYSCALL_TRACK(pre_mem_read, ...) and > SYSCALL_TRACK(pre_mem_write, ...). Yes, that's been fixed in the latest version (20030716). Thanks for the report. > One question: What's the difference between 'pre_mem_read' and > 'pre_mem_read_asciiz'? 'pre_mem_read_asciiz' indicates memory is being read which is a string, ie. a null-terminated sequence of chars; usually a pathname. 'pre_mem_read' is for any other block of memory being read, which usually (always?) requires an accompanying size argument. N |
|
From: Alex I. <ale...@in...> - 2003-07-22 17:43:32
|
SGkgYWxsIQ0KDQpQbGVhc2UsIGdpdmUgbWUgYSBoYW5kIHdpdGggdGhpcyAtIEkgYW0gdHJ5 aW5nIHRvIGluc3RhbGwgS2NhY2hlZ3JpbmQgMC4zYg0KYW5kIEkgY2Fubm90IGdldCBwYXN0 IGNvbmZpZ3VyYXRpb24gc3RhZ2UuIEkgaGF2ZSBSSCA4LjAgd2l0aCBRdCAgMy4wLjUtMTcN CmFuZCBLREUgMy4wLjVhLTQgUlBNcyBpbnN0YWxsZWQuICBLY2FjaGVncmluZCBjb25maWd1 cmUgY2FuIGZpbmQgUXQganVzdA0KZmluZSwgYnV0IGJhaWxzIG91dCBvbiBLREUgZGVwZW5k ZW5jaWVzLiAgVGhlIGNvbmZpZ3VyYXRpb24gY29tbWFuZCBpcyBsaWtlDQp0aGlzOg0KDQou L2NvbmZpZ3VyZSAtLXdpdGgtcXQtZGlyPS91c3IvbGliL3F0LTMuMC41IC0td2l0aC1nbnUt bGQNCi0tcHJlZml4PS91c3IgICAgICAgICAgICAgICAgICAgICAoSSB0cmllcyAtLXByZWZp eD0vdXNyL2xvY2FsIGFzIHdlbGwpDQoNClRoZSB0YWlsIG90IHRoZSBjb25maWd1cmUgb3V0 cHV0IGlzOg0KDQpjaGVja2luZyBmb3IgUXQuLi4gbGlicmFyaWVzIC91c3IvbGliL3F0LTMu MC41L2xpYiwgaGVhZGVycw0KL3Vzci9saWIvcXQtMy4wLjUvaW5jbHVkZSB1c2luZyAtbXQN CmNoZWNraW5nIGlmIFF0IGNvbXBpbGVzIHdpdGhvdXQgZmxhZ3MuLi4gbm8NCmNoZWNraW5n IGZvciBtb2MuLi4gL3Vzci9saWIvcXQtMy4wLjUvYmluL21vYw0KY2hlY2tpbmcgZm9yIHVp Yy4uLiAvdXNyL2xpYi9xdC0zLjAuNS9iaW4vdWljDQpjaGVja2luZyB3aGV0aGVyIHVpYyBz dXBwb3J0cyAtTCAuLi4geWVzDQpjaGVja2luZyB3aGV0aGVyIHVpYyBzdXBwb3J0cyAtbm91 bmxvYWQgLi4uIHllcw0KY2hlY2tpbmcgaWYgUXQgbmVlZHMgLWxqcGVnLi4uIG5vDQpjaGVj a2luZyBmb3IgcnBhdGguLi4geWVzDQpjaGVja2luZyBmb3IgS0RFLi4uIGNvbmZpZ3VyZTog ZXJyb3I6DQppbiB0aGUgcHJlZml4LCB5b3UndmUgY2hvc2VuLCBhcmUgbm8gS0RFIGhlYWRl cnMgaW5zdGFsbGVkLiBUaGlzIHdpbGwgZmFpbC4NClNvLCBjaGVjayB0aGlzIHBsZWFzZSBh bmQgdXNlIGFub3RoZXIgcHJlZml4IQ0KDQoNClBsZWFzZSwgbGV0IG1lIGtub3cgd2hhdCBJ IGFtIGRvaW5nIHdyb25nIGhlcmUuIEkganVzdCBob3BlIEkgd29uJ3QgaGF2ZSB0bw0KcmVj b21waWxlIEtERSBsb2NhbGx5IGhlcmUuIEkgd291bGQgYWxzbyBsaWtlIHRvIGluc3RhbGwg a2NhY2hlZ3JpbmcgaW4gYQ0KZGlmZmVyZW50IChzaGFyZWQgbmV0d29yaykgZGlyZWN0b3J5 LCB3aGVyZSB0aGVyZSBhcmUgZGVmaW5pdGVseSBubyBLREUNCmFydGlmYWN0cyAtIGl0IHRo YXQgaW1wb3NzaWJsZT8NCg0KVGhhbmtzIGZvciB5b3VyIGhlbHAhDQoNCkFsZXgNCg0KLS0N CkFsZXggRy4gSXZlcnNoZW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5ldCBUZWNo bm9sb2dpZXMsIEluYy4NCk5ldHdvcmsgUHJvZHVjdHMgRGVwdC4gICAgICAgICAgICAgICAg ICAgICAgMTUwMCBOLiBHcmVlbnZpbGxlIEF2ZS4NCkluZXQgVGVjaG5vbG9naWVzIEluYy4g ICAgICAgICAgICAgICAgICAgICAgUmljaGFyZHNvbiwgVFggNzUwODENClBob25lOiArMS00 NjktMzMwLTQyOTUgICAgICAgICAgICAgICAgICAgICAgVVNBDQoNCg0K |
|
From: Josef W. <Jos...@gm...> - 2003-07-22 22:47:14
|
On Tuesday 22 July 2003 19:43, Alex Ivershen wrote: > Hi all! > > Please, give me a hand with this - I am trying to install Kcachegrind 0.3b > and I cannot get past configuration stage. I have RH 8.0 with Qt 3.0.5-17 > and KDE 3.0.5a-4 RPMs installed. Kcachegrind configure can find Qt just > fine, but bails out on KDE dependencies. The configuration command is like > this: > > ./configure --with-qt-dir=/usr/lib/qt-3.0.5 --with-gnu-ld > --prefix=/usr (I tries --prefix=/usr/local as well) > > The tail ot the configure output is: Hi, I just don't know where KDE libs are installed on a Red Hat system, but you should be able to check with "kde-config --prefix". Perhaps you don't have developer-packages for kdelibs installed? The C++ headers are needed for compilation. Usually the package is called like "kdelibs-devel"... Or use a precompiled binary. At least KCachegrind 0.3a is available on http://apps.kde.com for Red Hat 8.0. > > checking for Qt... libraries /usr/lib/qt-3.0.5/lib, headers > /usr/lib/qt-3.0.5/include using -mt > checking if Qt compiles without flags... no > checking for moc... /usr/lib/qt-3.0.5/bin/moc > checking for uic... /usr/lib/qt-3.0.5/bin/uic > checking whether uic supports -L ... yes > checking whether uic supports -nounload ... yes > checking if Qt needs -ljpeg... no > checking for rpath... yes > checking for KDE... configure: error: > in the prefix, you've chosen, are no KDE headers installed. This will fail. > So, check this please and use another prefix! > > > Please, let me know what I am doing wrong here. I just hope I won't have to > recompile KDE locally here. I would also like to install kcachegring in a No panic ;-) Recompiling KDE is useless overkill for compiling a KDE app. > different (shared network) directory, where there are definitely no KDE > artifacts - it that impossible? Hmm... The "--prefix" option is the way to choose the path where KCachegrind should be installed. This doesn't have to be the same as the global KDE path on your system. Note that the headers should be found neverless (via kde-config) by configure. You only have to make sure after installing to another dir, that the executable is in the PATH and environment variable KDEDIR contains the prefix you have choosen. Josef > > Thanks for your help! > > Alex > > -- > Alex G. Ivershen Inet Technologies, Inc. > Network Products Dept. 1500 N. Greenville Ave. > Inet Technologies Inc. Richardson, TX 75081 > Phone: +1-469-330-4295 USA |