|
From: Eric H. <eri...@is...> - 2007-09-11 01:07:43
|
What would be involved in porting the latest version? It seems like FreeBSD has a version in the ports tree, but that version is really old. Also, the Valgrind Technical Documentation appears really out-of-date. In particular it doesn't seem to mention threads at all. Thanks, -- Eric Hopper <eri...@is...> Isilon Systems |
|
From: Paul F. <pj...@wa...> - 2020-06-25 18:13:37
|
Hi Today I fixed the last outstanding major issue with Valgrind on FreeBSD 12 amd64 with GCC. Whilst I’m aware that there is still much to do, I’d like to start discussing the requirements to get this code into the main sourceware repo. Is this mailing list the best place for discussion, or do you prefer bugzilla https://bugs.kde.org/show_bug.cgi?id=208531? <https://bugs.kde.org/show_bug.cgi?id=208531?> Less formally, I fairly often connect to the irc channel. A+ Paul |
|
From: Paul F. <pj...@wa...> - 2020-07-02 06:27:06
|
Well, let’s try to get the ball rolling. I’ll kick off with a few things here that I feel are not likely to be accepted. 1. Number of added ‘expected’ files. Currently there are 126 (and for comparison, Solaris only has about 30). About half of these are for Helgrind, which I’ll come to in a moment. I also generated expected files for Linux/clang to cover many of the clang vs. GCC issues. Some of those can probably be removed. Most of the clang diffs are due to clang generating fewer branches and using ‘cmov’ opcodes instead. This tends to cause errors to pop up later. For instance something like “printf(“foo %d”, cond ? a : b)” will generate an error at the call site with GCC but will cause more than one error in the libc printf internals with clang. I’ve also modified several of the test source files, either because they crash under FreeBSD (for instance, creating mutexes with completely bogus data) or because they don’t compile or because clang optimises away errors. Where there are blocks that are #ifdeffed out, a different expected is needed. One possible solution to the above would be to make a separate FreeBSD-only test - disable the original in the .vgtest file for FreeBSD and then copy the test to the appropriate FreeBSD directory. 2. Filter scripts. ‘sed' on FreeBSD is not GNU sed, which is an optional install as ‘used’. Rather than waste time debugging sed issues, and not being very expert with automake I just did a brute force change in the filter scripts that is basically “if uname == FreeBSD sed=gsed else sed=sed” and then use $sed. Making automake .in files would probably be cleaner. 3. Helgrind changes. The FreeBSD pthread* signatures do not end with @*. So I’ve changed the filter and expected files to strip the @*. There would be fewer changes if I reversed this (which would require a tool with regex lookahead). Lastly on Helgrind, when Valgrind is built with clang there is no function prolog generated for pthread/sem functions. As a consequence the generated stack traces are missing one of the ‘hg_intercepts.c’ lines. One possibility to avoid that would be to disable optimization for the Helgrind intercepts so that clang generates the prologs. I might also be able to use the same mechanism as is used for syscalls (which also don’t have any prolog). A+ Paul |
|
From: Ed M. <em...@fr...> - 2020-07-06 18:49:24
|
On Thu, 2 Jul 2020 at 02:27, Paul Floyd <pj...@wa...> wrote: > > Well, let’s try to get the ball rolling. I hope that after 10+ years we can finally get this into the main repository! > I’ll kick off with a few things here that I feel are not likely to be accepted. > > 1. Number of added ‘expected’ files. It sounds like for the most part these are a simple consequence of using Clang and such, and not really something that can be "fixed." > One possible solution to the above would be to make a separate FreeBSD-only test - disable the original in the .vgtest file for FreeBSD and then copy the test to the appropriate FreeBSD directory. To me this sounds broadly reasonable; we really need feedback from upstream maintainers on whether this is a viable approach. |
|
From: Paul F. <pj...@wa...> - 2020-07-06 21:12:44
|
Hi Ed and dev team >> > Well, let’s try to get the ball rolling.> > I hope that after 10+ years we can finally get this into the main repository! I'd like to think that this would benefit everyone. [expecteds] > It sounds like for the most part these are a simple consequence of > using Clang and such, and not really something that can be "fixed." There might be a few 'expecteds' that I added or changed by mistake but on the whole I've gone a long way to analyze exactly the cause of each difference. Using clang changes a lot, and also the fact that many tests use UB. FreeBSD UB is not always the same as Linux UB. I'll go into details on one testcase, helgrind/tests/tc01_simple_race. For a GCC build, this failed because FreeBSD pthread/sem functions don't have @version. So the change that I made was to strip "@*" with filter_stderr and to update all of the expecteds. I'm planning on reversing this change. In filter_stderr I'll append an "@*" and then I can restore the expecteds to their original state. This will require some more powerful regexp foo like perl -p -e "s/pthread_create(?!@\*)/pthread_create@*/" otherwise Linux will get "@*@*". For a clang build, this still failed. This time it's because clang does tail call elimination in the wrapper stubs in vgpreload_helgrind-amd64-freebsd.so. The result is one less line in the callstack. As luck would have it, it is one of the lines that is not filtered out. The easy answer to that was a clang expected file. Again it might be possible with enough perl to insert the missing line and have just one expected file. Looking at the diff when Solaris support was added (git diff ac60633d6576315eceffde476d2512e812ea513b^ ac60633d6576315eceffde476d2512e812ea513b) it seems there were also many similar changes then. A+ Paul |
|
From: Paul F. <pj...@wa...> - 2020-07-09 06:11:18
|
Hi again I’ve now cleaned out the helgrind regressions and I’m down to a much more reasonable +9 extra expected files. A+ Paul |
|
From: Ed M. <em...@fr...> - 2020-07-09 18:02:48
|
On Thu, 9 Jul 2020 at 02:11, Paul Floyd <pj...@wa...> wrote: > > Hi again > > I’ve now cleaned out the helgrind regressions and I’m down to a much more reasonable +9 extra expected files. Most excellent, thanks Paul. Julian et. al., can we get some guidance on the next steps for having this committed upstream? |
|
From: Peter B. <Pet...@xs...> - 2007-09-11 13:31:44
|
On Mon, Sep 10, 2007 at 06:07:46PM -0700, Eric Hopper wrote: > What would be involved in porting the latest version? It seems like > FreeBSD has a version in the ports tree, but that version is really old. >=20 > Also, the Valgrind Technical Documentation appears really out-of-date. > In particular it doesn't seem to mention threads at all. There's work in progress on the NetBSD port. Have a look at http://vg4nbsd.sourceforge.net for more information. If you have some time and energy to spend, we'd very much appreciate some help. The port currently works on simple programs. We need support for signal handling. Basically we are now ensuring that the tests run. It would be reasonably simple to port it to FreeBSD. There is also work being done by Apple on a port for Darwin, which would be similar, but this work will only be open sourced when it is finished. Cheers, Peter --=20 http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth |
|
From: Benjamin M. <be...@me...> - 2007-09-11 17:10:21
|
On Sep 11, 2007, at 3:31 PM, Peter Bex wrote: > There is also work > being done by Apple on a port for Darwin, which would be similar, > but this work will only be open sourced when it is finished. Do you have any more information about this? Is this something that someone at apple talked about doing or is actually doing? Any time table? -Benjamin Meyer |
|
From: Peter B. <Pet...@xs...> - 2007-09-11 17:19:25
|
On Tue, Sep 11, 2007 at 07:09:09PM +0200, Benjamin Meyer wrote: >=20 > On Sep 11, 2007, at 3:31 PM, Peter Bex wrote: >=20 > > There is also work > > being done by Apple on a port for Darwin, which would be similar, > > but this work will only be open sourced when it is finished. >=20 > Do you have any more information about this? Is this something that =20 > someone at apple talked about doing or is actually doing? Any time =20 > table? >=20 > -Benjamin Meyer See http://sourceforge.net/mailarchive/forum.php?thread_name=3D20070831232811.7= 178.qmail%40kaazh.pair.com&forum_name=3Dvalgrind-developers Peter --=20 http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth |
|
From: Benjamin M. <be...@me...> - 2007-09-11 18:06:10
|
Nice :) Hmm it probably wouldn't take much work (cross fingers) to get KCachegrind built on Qt4 only. Slap in a few OS X integration features and have a nice bundle to run on my laptop :) -Benjamin Meyer On Sep 11, 2007, at 7:18 PM, Peter Bex wrote: > On Tue, Sep 11, 2007 at 07:09:09PM +0200, Benjamin Meyer wrote: >> >> On Sep 11, 2007, at 3:31 PM, Peter Bex wrote: >> >>> There is also work >>> being done by Apple on a port for Darwin, which would be similar, >>> but this work will only be open sourced when it is finished. >> >> Do you have any more information about this? Is this something that >> someone at apple talked about doing or is actually doing? Any time >> table? >> >> -Benjamin Meyer > > See > http://sourceforge.net/mailarchive/forum.php? > thread_name=20070831232811.7178.qmail% > 40kaazh.pair.com&forum_name=valgrind-developers > > Peter > -- > http://sjamaan.ath.cx > -- > "The process of preparing programs for a digital computer > is especially attractive, not only because it can be economically > and scientifically rewarding, but also because it can be an aesthetic > experience much like composing poetry or music." > -- Donald Knuth > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Josef W. <Jos...@gm...> - 2007-09-12 13:54:22
|
On Tuesday 11 September 2007, Benjamin Meyer wrote: > Nice :) Hmm it probably wouldn't take much work (cross fingers) to > get KCachegrind built on Qt4 only. A little bit OT regarding the Valgrind, but ... Yes, porting KCachegrind to pure Qt should be quite easy, as it started in the very beginning as Qt application. I really like to split the sources up into data model stuff (lib/), Qt GUI stuff, and KDE additions, which would give 3 versions: console (filtering/merging of profile data, ASCII output results), pure Qt version, and KDE version. > Slap in a few OS X integration > features and have a nice bundle to run on my laptop :) This would be appreciated a lot. However, I do not have an Apple machine to test this. Josef |
|
From: Eric H. <eri...@is...> - 2007-09-11 18:41:25
|
On Tue, 2007-09-11 at 15:31 +0200, Peter Bex wrote: > On Mon, Sep 10, 2007 at 06:07:46PM -0700, Eric Hopper wrote: > > What would be involved in porting the latest version? It seems like > > FreeBSD has a version in the ports tree, but that version is really old. > > > > Also, the Valgrind Technical Documentation appears really out-of-date. > > In particular it doesn't seem to mention threads at all. > > There's work in progress on the NetBSD port. Have a look at > http://vg4nbsd.sourceforge.net for more information. Actually... http://vg4nbsd.berlios.de/ is the right URL. :-) > If you have some time and energy to spend, we'd very much appreciate > some help. The port currently works on simple programs. We need > support for signal handling. Basically we are now ensuring that the > tests run. It would be reasonably simple to port it to FreeBSD. > There is also work being done by Apple on a port for Darwin, which > would be similar, but this work will only be open sourced when it is > finished. I know very little about NetBSD vs. FreeBSD. Isn't it true that NetBSD uses a.out whereas FreeBSD uses ELF? Will this matter much as far as Valgrind is concerned? I know it will matter at least a little since Valgrind relies a bit on shared library hooks, but the description I see in the technical documentation section doesn't imply a major reliance on a particular object file format. But I can see a difference in object file format possibly posing a barrier to a NetBSD vs. a FreeBSD port. I'm concerned mainly with FreeBSD because the company I'm working for will need to modify it even further because the devices we sell use a somewhat modified FreeBSD kernel. I would love to be able to help, but in order to be paid to do so I need to be able to justify it to the people I'm working for. :-) Thanks, -- Eric Hopper <eri...@is...> Isilon Systems |
|
From: Nicholas N. <nj...@cs...> - 2007-09-11 22:39:19
|
On Tue, 11 Sep 2007, Eric Hopper wrote: > I know very little about NetBSD vs. FreeBSD. Isn't it true that NetBSD > uses a.out whereas FreeBSD uses ELF? Will this matter much as far as > Valgrind is concerned? I know it will matter at least a little since > Valgrind relies a bit on shared library hooks, but the description I see > in the technical documentation section doesn't imply a major reliance on > a particular object file format. It will matter a lot -- Valgrind has its own ELF loader. Although, does AIX use ELF or a.out? If the latter, then Valgrind must have its own a.out loader too, I think... Nick |
|
From: Paul M. <pa...@sa...> - 2007-09-12 01:37:57
|
Nicholas Nethercote writes: > It will matter a lot -- Valgrind has its own ELF loader. Although, does AIX > use ELF or a.out? If the latter, then Valgrind must have its own a.out > loader too, I think... Neither; AIX uses XCOFF. There is a description at http://www.unet.univie.ac.at/aix/files/aixfiles/XCOFF.htm (I haven't checked that page for accuracy; I just found it with a quick google search.) Paul. |
|
From: Kumar R. <kum...@gm...> - 2007-09-12 03:04:32
|
Curiosity Q. How did the topic switch to AIX ? And AFAIK, a.out format on most modern systems, rely on the native file format and is not really a separate file format by itself (it was in the earlier Unix days, but no longer so). According to this wiki, all BSD versions use ELF file format (include FreeBSD) http://en.wikipedia.org/wiki/A.out_(file_format) :-) - The problem with winning the rat race is that, even if u win, u r still a rat Kumar Rangarajan Senior Architect S7 Software Solutions "Where Migration Meets Innovation" On 12-Sep-07, at 7:02 AM, Paul Mackerras wrote: > Nicholas Nethercote writes: > >> It will matter a lot -- Valgrind has its own ELF loader. >> Although, does AIX >> use ELF or a.out? If the latter, then Valgrind must have its own >> a.out >> loader too, I think... > > Neither; AIX uses XCOFF. There is a description at > > http://www.unet.univie.ac.at/aix/files/aixfiles/XCOFF.htm > > (I haven't checked that page for accuracy; I just found it with a > quick google search.) > > Paul. > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Kailash S. <hs...@gm...> - 2007-09-12 03:35:05
|
Hi, Yes, NetBSD does use the ELF file format. If you are considering a freebsd port, you will be able to reuse a lot of the code in vg4nbsd. For example, you will be able to use the changes to the build system to introduce a new OS, implement stack based syscall argument passing ( this is implemented in as clean a manner as possible as the mainline code is catered for register based semantics). Getting aspacem working in *BSD will also be reusable. Definitely,the vg4nbsd port will serve as a good reference till the point you get to handling signals. I recommend that you branch off -current and use what you can from the vg4nbsd port. One mistake we have made is that we have incorporated changes from upstream into our code base, and this is pending a big exercise to fix. It will be good for you to maintain patches against -current to introduce FreeBSD support so you can continually sync more easily. Hope this helps, Kailash On 9/12/07, Kumar Rangarajan <kum...@gm...> wrote: > Curiosity Q. How did the topic switch to AIX ? > > And AFAIK, a.out format on most modern systems, rely on the native > file format and is not really a separate file format by itself (it > was in the earlier Unix days, but no longer so). According to this > wiki, all BSD versions use ELF file format (include FreeBSD) > > http://en.wikipedia.org/wiki/A.out_(file_format) > > :-) > > - > The problem with winning the rat race is that, even if u win, u r > still a rat > > Kumar Rangarajan > Senior Architect > S7 Software Solutions > "Where Migration Meets Innovation" > > On 12-Sep-07, at 7:02 AM, Paul Mackerras wrote: > > > Nicholas Nethercote writes: > > > >> It will matter a lot -- Valgrind has its own ELF loader. > >> Although, does AIX > >> use ELF or a.out? If the latter, then Valgrind must have its own > >> a.out > >> loader too, I think... > > > > Neither; AIX uses XCOFF. There is a description at > > > > http://www.unet.univie.ac.at/aix/files/aixfiles/XCOFF.htm > > > > (I haven't checked that page for accuracy; I just found it with a > > quick google search.) > > > > Paul. > > > > ---------------------------------------------------------------------- > > --- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |