|
From: Vikram C. <vik...@gm...> - 2017-09-19 21:50:44
|
Hi All, I am trying to run valgrind on our mips 64 bit platform. I have compiled valgrind 3.13 with following configure arguments: ./configure --host=mips64-poky-linux --prefix=... --build=x86_64-linux CC=... CXX=... My code access memory-address range starting from 0x8001180000000000. This is ligitimate access. We have added following valgrind macro in the code before this access as: VALGRIND_MALLOCLIKE_BLOCK(CVMX_ADD_IO_SEG(0x8001180000000000ull), 0x0000000000f00000ull, 0, 1); But when the code tries accessing the memory region, it simply terminates with SIGBUS: ==1492== Process terminating with default action of signal 10 (SIGBUS) If we remove the above valgrind macro, the program still terminates with SIGBUS with additional error message. ==890== Address 0x8001180000001500 is not stack'd, malloc'd or (recently) free' ==890== Process terminating with default action of signal 10 (SIGBUS) I have tried valgrind 3.12 with same issue. If I run any other application under valgrind that does not access this memory region, it works fine. Also, this application runs fine without valgrind. Please let me know what can we do to get around this issue. Thanks |
|
From: John R. <jr...@bi...> - 2017-09-19 22:00:50
|
> My code access memory-address range starting from 0x8001180000000000. This is legitimate access. But *what* does it access? Is it a memory-mapped hardware device, or is it real RAM? Actual memory can be accessed in smaller or larger pieces in any order, and give consistent answers. Many hardware devices cannot. If 0x8001180000000000 is a hardware device, then put a logic analyzer on the bus and find out exactly what is going on. If it's supposed to be actual RAM, then invoke valgrind with --trace-notbelow=0 --trace-flags=10000000 (warning: many megabytes of output) and examine the accesses there. -- |
|
From: Vikram C. <vik...@gm...> - 2017-09-19 22:23:20
|
Thanks John. It is memory-mapped hardware device. I will debug more and would update you. On Tue, Sep 19, 2017 at 3:00 PM, John Reiser <jr...@bi...> wrote: > My code access memory-address range starting from 0x8001180000000000. This >> is legitimate access. >> > > But *what* does it access? Is it a memory-mapped hardware device, or is > it real RAM? > Actual memory can be accessed in smaller or larger pieces in any order, > and give consistent answers. Many hardware devices cannot. If > 0x8001180000000000 > is a hardware device, then put a logic analyzer on the bus and find out > exactly what is going on. > If it's supposed to be actual RAM, then invoke valgrind with > --trace-notbelow=0 --trace-flags=10000000 > (warning: many megabytes of output) and examine the accesses there. > > -- > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Vikram C. <vik...@gm...> - 2017-10-03 20:53:29
|
Thanks a lot. This looks promising. I will try and get back to you. Vikram On Tue, Oct 3, 2017 at 4:01 AM, Maran Pakkirisamy < mpa...@ca...> wrote: > Probably your application is accessing xkphys address space on cavium > processor. > > Try this branch which has support for applications accessing xkphys > address space specifically on octeon processors. > https://github.com/valgrindocteon/valgrind/commits/devel/octeon3 > > You would have to add following command line switch when invoking valgrind > (to instruct valgrind to ignore xkphys address space) > > --ignore-ranges=0x8000000000000000-0xbfffffffffffffff > > > > On Wednesday 20 September 2017 03:20 AM, Vikram Chhibber wrote: > > Hi All, > > I am trying to run valgrind on our mips 64 bit platform. I have compiled > valgrind 3.13 with following configure arguments: > > ./configure --host=mips64-poky-linux --prefix=... --build=x86_64-linux > CC=... CXX=... > > My code access memory-address range starting from 0x8001180000000000. This > is ligitimate access. > We have added following valgrind macro in the code before this access as: > VALGRIND_MALLOCLIKE_BLOCK(CVMX_ADD_IO_SEG(0x8001180000000000ull), > 0x0000000000f00000ull, 0, 1); > > But when the code tries accessing the memory region, it simply terminates > with SIGBUS: > > ==1492== Process terminating with default action of signal 10 (SIGBUS) > > > If we remove the above valgrind macro, the program still terminates with > SIGBUS with additional error message. > > ==890== Address 0x8001180000001500 is not stack'd, malloc'd or > (recently) free' > > ==890== Process terminating with default action of signal 10 (SIGBUS) > > > I have tried valgrind 3.12 with same issue. If I run any other application > under valgrind that does not access this memory region, it works fine. > > Also, this application runs fine without valgrind. > > Please let me know what can we do to get around this issue. > > Thanks > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Valgrind-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > -- > Maran Pakkirisamy > > |
|
From: Vikram C. <vik...@gm...> - 2017-10-05 18:39:21
|
Thanks Maran. I am trying to compile this branch for mips and it is giving these errors: This is my configure string: ./configure --host=mips64-poky-linux --prefix=...install_oct CFLAGS=-mips64 --build=x86_64-linux CC=...mips64-poky-linux-gcc CXX=...mips64-poky-linux-g++ mv -f priv/.deps/libvex_mips64_linux_a-guest_s390_toIR.Tpo priv/.deps/libvex_mips64_linux_a-guest_s390_toIR.Po /home/vchhibbe/workspace/tools/1.6.2/sysroots/x86_64-pokysdk-linux/usr/bin/mips64-poky-linux/mips64-poky-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../include -I../VEX/pub -I../VEX/pub -DVGA_mips64=1 -DVGO_linux=1 -DVGP_mips64_linux=1 -DVGPV_mips64_linux_vanilla=1 -Ipriv -O2 -g -std=gnu99 -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wold-style-declaration -fno-stack-protector -fno-strict-aliasing -fno-builtin -Wbad-function-cast -fstrict-aliasing -mips64 -MT priv/libvex_mips64_linux_a-guest_mips_helpers.o -MD -MP -MF priv/.deps/libvex_mips64_linux_a-guest_mips_helpers.Tpo -c -o priv/libvex_mips64_linux_a-guest_mips_helpers.o `test -f 'priv/guest_mips_helpers.c' || echo './'`priv/guest_mips_helpers.c /tmp/ccr6aN6R.s: Assembler messages: /tmp/ccr6aN6R.s:995: Error: invalid operands `dmtc2 $4,0x256' /tmp/ccr6aN6R.s:1080: Error: invalid operands `dmtc2 $4,0x5C' /tmp/ccr6aN6R.s:1149: Error: invalid operands `dmtc2 $4,0x1207' /tmp/ccr6aN6R.s:1217: Error: invalid operands `dmtc2 $4,0x10C' /tmp/ccr6aN6R.s:1266: Error: invalid operands `dmtc2 $4,0x2C8' /tmp/ccr6aN6R.s:1316: Error: invalid operands `dmtc2 $4,0x245' /tmp/ccr6aN6R.s:1372: Error: invalid operands `dmtc2 $4,0x404F' /tmp/ccr6aN6R.s:1427: Error: invalid operands `dmtc2 $4,0x48' /tmp/ccr6aN6R.s:1462: Error: invalid operands `dmtc2 $4,0x2D0' /tmp/ccr6aN6R.s:1504: Error: invalid operands `dmtc2 $4,0x206' /tmp/ccr6aN6R.s:1545: Error: invalid operands `dmtc2 $4,0x25C' /tmp/ccr6aN6R.s:1586: Error: invalid operands `dmtc2 $4,0x3114' Please let me know if I am missing anything. Thanks On Tue, Oct 3, 2017 at 1:53 PM, Vikram Chhibber <vik...@gm...> wrote: > Thanks a lot. This looks promising. I will try and get back to you. > > Vikram > > On Tue, Oct 3, 2017 at 4:01 AM, Maran Pakkirisamy < > mpa...@ca...> wrote: > >> Probably your application is accessing xkphys address space on cavium >> processor. >> >> Try this branch which has support for applications accessing xkphys >> address space specifically on octeon processors. >> https://github.com/valgrindocteon/valgrind/commits/devel/octeon3 >> >> You would have to add following command line switch when invoking >> valgrind (to instruct valgrind to ignore xkphys address space) >> >> --ignore-ranges=0x8000000000000000-0xbfffffffffffffff >> >> >> >> On Wednesday 20 September 2017 03:20 AM, Vikram Chhibber wrote: >> >> Hi All, >> >> I am trying to run valgrind on our mips 64 bit platform. I have compiled >> valgrind 3.13 with following configure arguments: >> >> ./configure --host=mips64-poky-linux --prefix=... --build=x86_64-linux >> CC=... CXX=... >> >> My code access memory-address range starting from 0x8001180000000000. >> This is ligitimate access. >> We have added following valgrind macro in the code before this access as: >> VALGRIND_MALLOCLIKE_BLOCK(CVMX_ADD_IO_SEG(0x8001180000000000ull), >> 0x0000000000f00000ull, 0, 1); >> >> But when the code tries accessing the memory region, it simply terminates >> with SIGBUS: >> >> ==1492== Process terminating with default action of signal 10 (SIGBUS) >> >> >> If we remove the above valgrind macro, the program still terminates with >> SIGBUS with additional error message. >> >> ==890== Address 0x8001180000001500 is not stack'd, malloc'd or >> (recently) free' >> >> ==890== Process terminating with default action of signal 10 (SIGBUS) >> >> >> I have tried valgrind 3.12 with same issue. If I run any other >> application under valgrind that does not access this memory region, it >> works fine. >> >> Also, this application runs fine without valgrind. >> >> Please let me know what can we do to get around this issue. >> >> Thanks >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> >> >> _______________________________________________ >> Valgrind-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> -- >> Maran Pakkirisamy >> >> > |