|
From: Michael D. C. <cra...@go...> - 2004-07-05 02:47:11
|
I have a large and complex embedded application which appears to have an uninitialized variable. Someone suggested to me I try using valgrind to find it. How hard would it be for me to embed valgrind in my firmware? Unfortunately, it's not an x86 CPU, it's a TI DSP chip, the 6713. It seems that if I initialize each byte of my target's memory to one value before loading my firmware, my application will work properly. But if I initialize it to a different value, it will work incorrectly every time. If I don't initialize any particular way, it will have sporadically buggy behavior. I'm not very familiar with valgrind. From a first look at your site, it seems that I will both need to make it support my DSP's instruction set, and I'll need to make it work within my target's firmware, running on Texas Instruments' DSP/BIOS real time operating system. If you think this would take me a long time to do, I'll have to find another way to debug it, as my client very urgently needs me to fix this. My application has about 70 source files, some of them very long, written in C. It's very dependent on the DSP/BIOS OS, and it has a device driver to interface with a firewire link layer chip. There are about a dozen tasks. The test that exhibits the bug involves communicating with a firewire disk drive. This suggests it would be very difficult to get my code to run in any kind of simulator on a desktop OS. If valgrind won't work for me, perhaps you can suggest a more suitable tool. Or if you think valgrind WILL work for me, perhaps you can give me some tips on how to get started. Thanks! Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com cra...@go... Tilting at Windmills for a Better Tomorrow. "I give you this one rule of conduct. Do what you will, but speak out always. Be shunned, be hated, be ridiculed, be scared, be in doubt, but don't be gagged." -- John J. Chapman, "Make a Bonfire of Your Reputations" http://www.goingware.com/reputation/ |
|
From: Patrick M. <un...@pa...> - 2004-07-05 04:57:07
|
Hey Micheal (of irate fame), Valgrind has two restrictions, you must be running x86, and you must be running linux. So, in both cases, you are probably screwed. In your case with initalization, it seems some variables in your programs arnt initalizing the variable themselves (many programs do this, and shouldnt.) I suggest you write 0s to all the memory before loading the firmware if you arnt willing to fix the code. On 04-Jul-2004, Michael D. Crawford wrote: > I have a large and complex embedded application which appears to have an= =20 > uninitialized variable. Someone suggested to me I try using valgrind to= =20 > find it. How hard would it be for me to embed valgrind in my firmware?= =20 > Unfortunately, it's not an x86 CPU, it's a TI DSP chip, the 6713. >=20 > It seems that if I initialize each byte of my target's memory to one valu= e=20 > before loading my firmware, my application will work properly. But if I= =20 > initialize it to a different value, it will work incorrectly every time. = =20 > If I don't initialize any particular way, it will have sporadically buggy= =20 > behavior. >=20 > I'm not very familiar with valgrind. From a first look at your site, it= =20 > seems that I will both need to make it support my DSP's instruction set,= =20 > and I'll need to make it work within my target's firmware, running on Tex= as=20 > Instruments' DSP/BIOS real time operating system. >=20 > If you think this would take me a long time to do, I'll have to find=20 > another way to debug it, as my client very urgently needs me to fix this. >=20 > My application has about 70 source files, some of them very long, written= =20 > in C. It's very dependent on the DSP/BIOS OS, and it has a device driver= =20 > to interface with a firewire link layer chip. There are about a dozen= =20 > tasks. The test that exhibits the bug involves communicating with a=20 > firewire disk drive. This suggests it would be very difficult to get my= =20 > code to run in any kind of simulator on a desktop OS. >=20 > If valgrind won't work for me, perhaps you can suggest a more suitable=20 > tool. Or if you think valgrind WILL work for me, perhaps you can give me= =20 > some tips on how to get started. >=20 > Thanks! >=20 > Mike > --=20 > Michael D. Crawford > GoingWare Inc. - Expert Software Development and Consulting > http://www.goingware.com > cra...@go... >=20 > Tilting at Windmills for a Better Tomorrow. >=20 > "I give you this one rule of conduct. Do what you will, but speak > out always. Be shunned, be hated, be ridiculed, be scared, > be in doubt, but don't be gagged." > -- John J. Chapman, "Make a Bonfire of Your Reputations" > http://www.goingware.com/reputation/ >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20 > digital self defense, top technical experts, no vendor pitches,=20 > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users >=20 --=20 Patrick "Diablo-D3" McFarland || un...@pa... "Computer games don't affect kids; I mean if Pac-Man affected us as kids, w= e'd=20 all be running around in darkened rooms, munching magic pills and listening= to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 |
|
From: Julian S. <js...@ac...> - 2004-07-05 08:33:36
|
That sounds like a nasty problem. Making V work for your DSP is would take some months, so that's not a viable option, and it sounds like porting the app to x86-linux isn't viable either. The only thing I can think of is to do a binary search with your initialisation of the target memory. For example, suppose the memory size is 16MB (24 bits). First do a test in which memory is initialised iff bit 23 of the address is 1, and a second test iff bit 23 is 0. This tells you which half of the address space the uninitialised value(s) lie. Then bisect again the must-be-initialised half. Etc. I used binary searching a lot to debug valgrind's CPU simulation early on. Keep accurate notes; I found it easy to get confused. J On Monday 05 July 2004 03:14, Michael D. Crawford wrote: > I have a large and complex embedded application which appears to have an > uninitialized variable. Someone suggested to me I try using valgrind to > find it. How hard would it be for me to embed valgrind in my firmware? > Unfortunately, it's not an x86 CPU, it's a TI DSP chip, the 6713. > > It seems that if I initialize each byte of my target's memory to one value > before loading my firmware, my application will work properly. But if I > initialize it to a different value, it will work incorrectly every time. > If I don't initialize any particular way, it will have sporadically buggy > behavior. > > I'm not very familiar with valgrind. From a first look at your site, it > seems that I will both need to make it support my DSP's instruction set, > and I'll need to make it work within my target's firmware, running on Texas > Instruments' DSP/BIOS real time operating system. > > If you think this would take me a long time to do, I'll have to find > another way to debug it, as my client very urgently needs me to fix this. > > My application has about 70 source files, some of them very long, written > in C. It's very dependent on the DSP/BIOS OS, and it has a device driver to > interface with a firewire link layer chip. There are about a dozen tasks. > The test that exhibits the bug involves communicating with a firewire disk > drive. This suggests it would be very difficult to get my code to run in > any kind of simulator on a desktop OS. > > If valgrind won't work for me, perhaps you can suggest a more suitable > tool. Or if you think valgrind WILL work for me, perhaps you can give me > some tips on how to get started. > > Thanks! > > Mike |