Linux have very powerful tool called "Valgrind" , which used for detecting memory leaks, bugs, errors. Can be used as "profiler" to found bottlenecks and alt. That is only few features which are pretty interesting.
Tool are GPL, working on Linuxes (include ppc32 versions) and MacOS, so i in interest did someone already tried to port it before ?
Valgrind is a fantastic tool but I don't think it is possible to port it to OS4. I suppose it uses too many Linux specific functions and also relies on multiple address space features.
This afternoon, after I read your thread about a crash of LodePaint, I got the sources to compile it on Linux and run with Valgrind ! Unfortunately I stopped because I had an error in the SDL init due to X.
For days, I think about this king of software, that would be great to have for example an emulator that will track resources and bad accesses, that would be able to give statistics on the used memory, etc.
Why i ask about it: because Lode (author of LodePaint), say that he run program on linux over Valgrind, and Valgrind show him some errors, but not the same which i have by MemGuard. So for us not GR, not MemGuard show all the problems, which for our OS where errors are matter are bad.
And because of it i think that will be cool to have Valgrind on aos4. Maybe need to try to contact with authors, just to ask about all those dependeces and possibility to port to aos4
As i check from souces, all these tools (include MemCheck) are modules of ValGrind. I.e. you can't run just "memcheck program.exe", but you should run it like: "ValGrind --leak-check=yes program.exe". --leak-check=yes option mean here usage of memcheck module.
So ValGrind itself still should be ported. I will take at it more deeply, and will try to write to authors, maybe they will be in interest to help with port to aos4.
- after checking if possible or not to do that on AOS4 (no additionnal libraries from linux needded,...
- After checking if Valgrind is the best candidate...
I let kas1e or corto or anothers programmers to give their point of view here....
Sorry for the post on the other thread. Just happily surprised to know that in one day the original lodepaint author arrive to correct all the memory leak on lodepaint
Also too bad GDB not work. No amiga programmers surely laugh at us We are not serious......
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
I test default GDB from latest SDK for now, and, on stripped LodePaint binary - it runs (strip mean removing all debug and unimportant for usage information from binary, which mean binary smaller, but, that also mean - not debug information which are very important for bug hunting). For plain, unstripped binary (45mb), it crashes heavy in elf.library.
Related to Valgrind: right now i download the very first version , the middle one and the latest one: all versions (and programm itself) heavy based on CPU and on OS itself. The first ones was only x86/linux. The latest one are support PPC already (already good), but of course have no support for AmigaOS at all.
With such kind of utilityes, OS are matter (exactly OS), because of all that static addresses and alt. For example, on some linuxes back in the past "stack" for user process always was started at 0xBFFFFFFF (if i remember right), but of course, for AmigaOS it will be 100% and absolutly different (but programm can use stack for , and that adresses - so, that is very OS specific).
That what say Valgrinds authors about port: Quote:
Valgrind 3.X has the infrastructure to support multiple platforms. A platform is a specific (CPU,OS) pairing, such as x86/Linux or AMD64/Linux.
Maintaining each port takes a lot of effort, more so than for most other programs. Valgrind is fragile due to the low-level nature of what it does. Also, each platform port has CPU-specific code, OS-specific code and platform-specific code, and testing all the combinations is difficult.
Because of this, we can only justify supporting platforms that are widely used. Unlike NetBSD or GCC, we are not interested in having Valgrind work on every platform in the known universe: the maintenance burden is too high. Therefore, porting Valgrind to different platforms is not simply a technical exercise: you also need to make a convincing case that the effort will be worth it, and that the port will be supported properly, at least in the foreseeable future. The following table summarises our current porting priorities.
Anyway, i think it still possible to port, but of course huge job. With having in mind that all the coders on amiga today (include me) are suck , it will be pretty hard to found someone who will works on it. Basically, if PPC support are done already, then, maybe it will be not _that_ hard. But its time consuming project, and for sure need create a bounty.
Maybe, if we will send "free" sam for one of authors, and make bounty and collect some money for , then, it can be reality (maybe).
PS. Also there is a MacOS X port (only x86/amd), and someone can think that if it have MacOS then AOS4 can too, but , MacOSX its in general the same as FreeBSD by indeep details what not so different with linux (all that glibc, and alt). AOS4 in that terms "a bit" different.
So the Valgrind people of course will think AmigaOS as a no priority to port Valgrind to. It's GPL. If someone is interested, they can do whatever they want with the code, and make an unofficial port.
I will have a look at the Valgrind sources but I am pretty sure it won't be possible to port it.
Mrodfr : You talk about oprofile. With Valgrind, they are maybe the best development tools on Linux in my opinion. oprofile is a profiler and for people who work on Linux, you should try Zoom, from RotateRight that has an interface and uses oprofile drivers or their own. I registered, the tool is great and the support is really efficient too.
About oprofile, I developed Hieronymus thinking about it. Due to a bug in OS4 on Pegasos and Sam440, it only works on AOne for now but it gives basically the same information (look at my article about it in the last issue of aMiGa=PoWeR).
I think it you will in interest to port Valgind, we can works on it together. For first we (i for example) can write just a mail to developers, and ask : what we should add to make it works on aos4.
PPC cpu support already done (maybe only need few modification in terms of gateway beetwen program and cpu). I think we need just new addresses of memory functions (malloc, etc), which in Valgrind grabs from Libc (which, we also have).
It 100% can't be "./configure + make" (because i already try it, and on ./configure it say - ppc cpu support yes, amigaos support - no , please port yourself" ). But imho still it possible. If you in interst to try, i can write message to author, and so on ..
I haven't knowledge about this subject but I often send DSI or memguard hits and programmers have allways difficulties to found or to locate well where are the problem.
I would like to have more than DSI and memguard (hum, also a broken GDB) and hymeninus (not work on SAM unfortunately) for helping programmers to found easily the problem on their software.
AOS4 should have an advanced program to found problem or to profile an AOS4 program. I'm ready to put some money for a bounty for that, maybe for @corto and @kas1e ???????
@kas1e: thanks for giving a try on valgrind...
I don't know where you found all this time to be so active for the amiga thanks a lot for that....
@corto
Hyemonimus not work on SAM. this problem is surely on the bugzilla ??? If not, open a thread for this subject on the AOS4 report problem thread on amigans...
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
I have tried to port valgrind myself a while ago. As it seemed to be a very difficult task (lot of #ifdef linux inside the code), I decided to start an own valgrind implementation, which is based on libvex, which is the core of valgrind, and works out of the box on amiga OS. Libvex is the part that is responsible to convert the binary code to the IR code and vice versa. I made good progress (it is possible to detect bugs for a quite limited number of instructions) but I couldn't do more than that (so a lot of work is still ahead) due to some other priorities.
If anyone is interested in helping me out please contact me by email (mail@<my domain). I can easily prepare the code and upload it to adtools project on sourceforge then, where the development should ultimately should take place.
If Hyperion plans on porting LLVM to get the XCore-enhancements into AmigaOS, a better use of effort would be to check into SafeCode for LLVM on some currently-supported LLVM-based system.
I'd like to revive this old thread, because there is a need for debugging tools and I don't know if anyone did any further work on valgrind, and if it is possible to be ported.
@walkero GDB is much simpler to port in compare with Valgrind, and so far no one do so. I am even start something to give all the basics so only "progammers work" need it , and there even was BilliFish who was about to start doing something, but everything ends up with no result. But making GDB is really more or less easy with what we have already once there will be find any developer willing spend time on.
With our current situation with developers, Valgrind also out of question. But having working and not crashing GDB, with remove debugging will be more than enough and pretty possible (MorphOS guys have some more or less latest version already).
Valgrind is pretty much Linux only. No point in even trying. A much better ide IMO is to try to isolate the hairy parts of your code and to keep them platform agnostic and use Valgrind for those parts only.
An interesting approch is to use AxRuntime to run your complete Amiga program on Linux. Then you must avoid OS4 specific things though.
I used the first approach for InstallerLG and it helped me alot. Tried AxRuntime as well and could get my MUI application to run in an hour or so. AxRuntime deserves more attention I think, it's a very interesting project.
I was a not aware about AxRuntime. I just had a quick look at it, so I don't know really how that works but thanks, the approach seems to be very good. Could be really useful.
Your advice about trying to design software in order to have some parts independent and testable / able to work on Linux for example, is very good (having testing in mind also helps).
To come back to Valgrind, I agree, this Linux tool clearly relies on mechanisms we won't have on OS4.
@all
To avoid confusion, Valgrind is not a debugger like GDB. Valgrind (and more exactly its tool/option memcheck) is used to track bad memory behaviors. Note that gcc and clang "address sanitizer" is very good on that point (but not accessible for us).
Personal note: Please, don't reopen 10-year old threads