|
From: Julian S. <js...@ac...> - 2005-03-05 00:56:59
|
It seems to me we should be very close to a 2.4.0 freeze. Jeremy, is that indeed the situation? What other changes need to go into the code base? I've been looking into doing the merge and have been assembling tools and techniques for it. I'm going to do a 3-way merge based on the current svn head, the current cvs head and their most recent common ancestor (cvs at 11/19/2004 17:45:00 GMT). The amd64 stuff now works well enough that there is no point in trying to make the old threading stuff work on it. Instead we should just merge everything together and have done. I'm sure it will be a bit messy for a while. What I therefore need to decide is exactly when to snapshot the current cvs. The freeze-for-2.4.0 point seems a good place to me, and so I am hoping it can be frozen by the end of Sunday as I want to do the merge starting Monday. That freeze period will then remain in place for perhaps a week, by which time I'll have a good idea how hard the problem is, and so it'll be clearer how to move forward from there. J |
|
From: Jeremy F. <je...@go...> - 2005-03-05 01:24:10
|
Julian Seward wrote: >It seems to me we should be very close to a 2.4.0 freeze. >Jeremy, is that indeed the situation? What other changes need >to go into the code base? > > Nothing, as far as I'm concerned. I have some packaging and documentation changes still pending, but they won't impact the merge. I'm thinking of doing an -rc1 packaged version later today and publicise it a bit to get some wider testing, then fix up any problems and call the result 2.4.0. If there are any changes, I expect they'll be easy to sync up with the post-merge base. >What I therefore need to decide is exactly when to snapshot the >current cvs. The freeze-for-2.4.0 point seems a good place to >me, and so I am hoping it can be frozen by the end of Sunday >as I want to do the merge starting Monday. That freeze period >will then remain in place for perhaps a week, by which time I'll >have a good idea how hard the problem is, and so it'll be clearer >how to move forward from there. > I think you could do it now. If there are any subsequent changes, they can easily be folded in. If you're talking about when to cut over to using SVN for mainline development, that's a slightly different question. It seems to me that we should: 1. migrate the CVS mainline to SVN, ideally with history 2. create the 2.4 branch 3. merge the Vex line into mainline If the Vex-mainline merge commit happens before the CVS migration, we'll end up with broken history. Are you thinking we'll cut over the SVN instantaneously, or maintain parallel CVS and SVN lines for a while? Is the SVN server ready for public access? How about bugs? Are we going to continue using kde bugzilla, or start a new bug system? kde.org's CVS/bugzilla integration is rather nice; would we be able to reproduce that? J |
|
From: Nicholas N. <nj...@cs...> - 2005-03-05 01:42:44
|
On Fri, 4 Mar 2005, Jeremy Fitzhardinge wrote: > Nothing, as far as I'm concerned. I have some packaging and > documentation changes still pending, but they won't impact the merge. > I'm thinking of doing an -rc1 packaged version later today and publicise > it a bit to get some wider testing, then fix up any problems and call > the result 2.4.0. What about making --leak-check=yes the default? That's going to affect a lot of regtests; specifying --leak-check=no in the .vgtest files would be the easy fix. > If you're talking about when to cut over to using SVN for mainline > development, that's a slightly different question. It seems to me that > we should: > > 1. migrate the CVS mainline to SVN, ideally with history > 2. create the 2.4 branch > 3. merge the Vex line into mainline > > If the Vex-mainline merge commit happens before the CVS migration, we'll > end up with broken history. Broken history will be hard to avoid, to at least some extent -- either the post-split CVS history will be lost, or the post-split SVN history will be lost. (The SVN tree has the pre-split history, since it was imported from CVS.) > Are you thinking we'll cut over the SVN instantaneously, or maintain > parallel CVS and SVN lines for a while? That's a good question. Basically, it boils down to "what's happening between 2.4.0 and 3.0.0?" Ie. should we put bug fixes in CVS in anticipation of a 2.4.1? > How about bugs? Are we going to continue using kde > bugzilla, or start a new bug system? kde.org's CVS/bugzilla integration > is rather nice; would we be able to reproduce that? I think we should keep using KDE Bugzilla; it works well, and it has the history. I think the CVS/bugzilla integration is unimportant; so you can CC the diff to the bug report, that doesn't seem so great to me, you can do it manually in 20 seconds. N |
|
From: Jeremy F. <je...@go...> - 2005-03-05 01:48:47
|
Nicholas Nethercote wrote:
> What about making --leak-check=yes the default? That's going to
> affect a lot of regtests; specifying --leak-check=no in the .vgtest
> files would be the easy fix.
Did we decide on --leak-check=summary or full/yes as the default?
Summary prints a message about using full to see the details.
We could either edit all the .vgtest files, or all the stderr.exp
files. Or change vgtest itself to always supply --leak-check=no as an arg.
> That's a good question. Basically, it boils down to "what's happening
> between 2.4.0 and 3.0.0?" Ie. should we put bug fixes in CVS in
> anticipation of a 2.4.1?
We need to maintain 2.4.x, and also have the development version visible
for people to work with. Particularly since we want people to start
seriously porting it to other CPUs and OSs once Vex is in.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-05 02:03:51
|
On Fri, 4 Mar 2005, Jeremy Fitzhardinge wrote: > Did we decide on --leak-check=summary or full/yes as the default? Julian said: Ok. I change my vote. Let's have --leak-check=yes|summary|no, with the default being yes, and summary ... well, just producing a summary. When =yes is in effect, we should also print a line saying "use ...=summary or ...=no to reduce the amount of output." > We could either edit all the .vgtest files, or all the stderr.exp > files. Or change vgtest itself to always supply --leak-check=no as an arg. I worry that turning on the leak checker in all the tests will cause lots of failures -- the leak check numbers seem a bit variable. I vote for editing all the .vgtest files. N |
|
From: Jeremy F. <je...@go...> - 2005-03-05 20:36:03
|
Nicholas Nethercote wrote:
> Julian said:
>
> Ok. I change my vote. Let's have --leak-check=yes|summary|no,
> with the default being yes, and summary ... well, just producing
> a summary. When =yes is in effect, we should also print a line
> saying "use ...=summary or ...=no to reduce the amount of output."
>
Well, in use over the last few days, I've found --leak-check=summary is
the most useful default. It tells you whether there are definite leaks,
and suggests using --leak-check=full to see the details.
My preference would be to make it the default, and change the test
scripts to use --leak-check=no to save on having to fiddle all the .exp
files.
J
|
|
From: Dirk M. <dm...@gm...> - 2005-03-07 14:18:35
|
On Saturday 05 March 2005 02:23, Jeremy Fitzhardinge wrote: > If the Vex-mainline merge commit happens before the CVS migration, we'll > end up with broken history. I'm not sure if you're following KDE development, but KDE is switching to SVN pretty soon (within the next few weeks). Dirk |
|
From: Robert W. <rj...@du...> - 2005-03-05 01:34:59
|
Julian Seward wrote: > It seems to me we should be very close to a 2.4.0 freeze. > Jeremy, is that indeed the situation? What other changes need > to go into the code base? Can you give me a day to get the valgrind(1) manual page in there? |
|
From: Julian S. <js...@ac...> - 2005-03-05 16:02:32
|
> > If the Vex-mainline merge commit happens before the CVS migration, we'll > > end up with broken history. > > Broken history will be hard to avoid, to at least some extent -- either > the post-split CVS history will be lost, or the post-split SVN history > will be lost. (The SVN tree has the pre-split history, since it was > imported from CVS.) s/hard/impossible/g History is nice to have, but it's not critical. If there are any critical history items on the cvs trail that ought to be kept, we can post-hoc modify the svn log entries if needed. I'm not going to go to major effort to maintain/merge precise history. I've never found it terribly useful. If I wanted to spend an extra chunk of time in this process, it'd be more useful to write some top level overviews for some of our critical but underdocumented subsystems. Those sorts of overviews would have saved me many hours recently, and they make it easier for newcomers to contribute usefully. Currently our barrier to entry is too high. > > Are you thinking we'll cut over the SVN instantaneously, or maintain > > parallel CVS and SVN lines for a while? > > That's a good question. Basically, it boils down to "what's happening > between 2.4.0 and 3.0.0?" Ie. should we put bug fixes in CVS in > anticipation of a 2.4.1? We'll have to keep the 2.4 line alive for a while, probably in kde's cvs, so we can put critical bug fixes on it. I'm not in favour of doing any real development on the 2.4 line once it's out (else why call it a stable branch ?) I also think that 2.4's lure will diminish rapidly as the 3.0 line comes together. Although the merging is likely to be bumpy, once that's done I don't foresee major delays in getting usably stable builds from that line. Vex's x86 support is already pretty much as solid as the old UCode line, and in some ways better. What's between 2.4 and 3.0 ? What I want to do is: * Rewrite the low level memory manager, for the reasons already discussed at length. * Restructure the coregrind/ swamp into separate, well-defined subsystems. * Make amd64 work as well as x86. * Put primary emphasis on better structure, clarity and maintainability of the system as a whole. I've noticed that neglect of these things over the long term is a leading cause of death/abandonment of software systems, and I don't want Valgrind to fall into that trap. My goal for 3.0 is to support x86-linux, amd64-linux and possibly ppc32-linux. I'm not interested in merging support for alternative OSs until after that point, although I do of course hope that folks like GregP can start to construct changesets based on the 3.0 branch for supporting other OSs. Once past 3.0, we can figure out how to fold those in. I would like to have the source base shaping up for a 3.0 release by June 05. > > How about bugs? Are we going to continue using kde > > bugzilla, or start a new bug system? kde.org's CVS/bugzilla integration > > is rather nice; would we be able to reproduce that? Let's stick with kde's bugzilla for a while, and with SF's lists. There's already a lot changing at once here, and those work well for us. J |
|
From: Oswald B. <os...@kd...> - 2005-03-05 19:21:53
|
On Sat, Mar 05, 2005 at 04:02:19PM +0000, Julian Seward wrote: > We'll have to keep the 2.4 line alive for a while, probably in kde's > cvs, so we can put critical bug fixes on it. > are you aware of the fact that the migration of kde's cvs to svn is a matter of a few weeks according to the current plan? -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Nicholas N. <nj...@cs...> - 2005-03-06 05:39:53
|
On Sat, 5 Mar 2005, Julian Seward wrote: > What's between 2.4 and 3.0 ? What I want to do is: > > * Rewrite the low level memory manager, for the reasons already > discussed at length. > > * Restructure the coregrind/ swamp into separate, well-defined > subsystems. > > * Make amd64 work as well as x86. > > * Put primary emphasis on better structure, clarity and > maintainability of the system as a whole. I've noticed that > neglect of these things over the long term is a leading cause > of death/abandonment of software systems, and I don't want > Valgrind to fall into that trap. I would guess that the structure stuff is a more long-term thing -- it can certainly be started now, but I don't imagine everything can be partitioned nicely before June. N |
|
From: Julian S. <js...@ac...> - 2005-03-06 15:05:45
|
> > * Put primary emphasis on better structure, clarity and > > maintainability of the system as a whole. I've noticed that > > neglect of these things over the long term is a leading cause > > of death/abandonment of software systems, and I don't want > > Valgrind to fall into that trap. > > I would guess that the structure stuff is a more long-term thing -- it can > certainly be started now, but I don't imagine everything can be > partitioned nicely before June. Yes, I was just thinking that. Fixing up the current merge, getting amd64 to work well, and rewriting the address-space manager are probably as much as is realistically achievable in that timeframe. J |
|
From: Josef W. <Jos...@gm...> - 2005-03-06 19:30:51
Attachments:
symbol_hook.patch
|
Hi, On Saturday 05 March 2005 01:56, Julian Seward wrote: > It seems to me we should be very close to a 2.4.0 freeze. may I ask for a small set of additional tool API functions? I'm currently working on data structure related profiling info, and for that to be acceptable, I need to maintain a mapping table from address to objects. For static objects, I have to hook into symbol loading, and that is what the tool API addition is for. Josef |
|
From: Julian S. <js...@ac...> - 2005-03-07 00:24:00
|
Josef Really we are very close to a 2.4 release, and I don't want to put in new code at this point. We are doing docs-only changes now, and I want to ship 2.4 asap. New functionality can go into the 3.0 dev branch, which in any case will cause other changes for Calltree since there is a new IR (UCode is dead). J On Sunday 06 March 2005 19:27, Josef Weidendorfer wrote: > Hi, > > On Saturday 05 March 2005 01:56, Julian Seward wrote: > > It seems to me we should be very close to a 2.4.0 freeze. > > may I ask for a small set of additional tool API functions? I'm currently > working on data structure related profiling info, and for that to be > acceptable, I need to maintain a mapping table from address to objects. For > static objects, I have to hook into symbol loading, and that is what the > tool API addition is for. > > Josef |
|
From: Jeremy F. <je...@go...> - 2005-03-07 02:12:38
|
Julian Seward wrote:
>Josef
>
>Really we are very close to a 2.4 release, and I don't want to put
>in new code at this point. We are doing docs-only changes now, and
>I want to ship 2.4 asap.
>
>New functionality can go into the 3.0 dev branch, which in any case
>will cause other changes for Calltree since there is a new IR (UCode
>is dead).
>
I expect there'll be a 2.4.1 before 3.0 anyway. 2.4 is much more likely
to be in the next distro cycle.
J
|
|
From: Josef W. <Jos...@gm...> - 2005-03-07 12:45:41
|
On Monday 07 March 2005 01:23, Julian Seward wrote: > Josef > > Really we are very close to a 2.4 release, and I don't want to put > in new code at this point. We are doing docs-only changes now, and > I want to ship 2.4 asap. > > New functionality can go into the 3.0 dev branch, which in any case > will cause other changes for Calltree since there is a new IR (UCode > is dead). Hi, no problem on my side. I simply was not sure if a few small hooks for tools would still be able to make it in. For 3.x, it would be good if the debug reader could get a nice request interface inside of the tool API, e.g. iterators over functions, source lines, but also static data structures and type info. Regarding the new IR, I don't think there will be too much changes. Calltree, like Cachegrind, never used UCode directly. On Monday 07 March 2005 02:28, Jeremy Fitzhardinge wrote: > This patch makes everything fail with > > Tool error: > The tool you have selected is missing the function `track_new_segment', > which is required. Oopps. I had the hooks always above the ":track" line in toolfuncs.def, but moved it more to the bottom as for the first part, function invocations seemed to depend on some VG_(needs). What is the difference here? Josef |
|
From: Nicholas N. <nj...@cs...> - 2005-03-07 15:11:55
|
On Mon, 7 Mar 2005, Josef Weidendorfer wrote: > Regarding the new IR, I don't think there will be too much changes. > Calltree, like Cachegrind, never used UCode directly. Er, yes it does! See SK_(instrument)() :) N |
|
From: Jeremy F. <je...@go...> - 2005-03-07 16:30:37
|
Josef Weidendorfer wrote:
>On Monday 07 March 2005 02:28, Jeremy Fitzhardinge wrote:
>
>
>>This patch makes everything fail with
>>
>>Tool error:
>> The tool you have selected is missing the function `track_new_segment',
>> which is required.
>>
>>
>
>Oopps. I had the hooks always above the ":track" line in toolfuncs.def, but
>moved it more to the bottom as for the first part, function invocations
>seemed to depend on some VG_(needs). What is the difference here?
>
If you use SK_(X) directly, then it will simply try to call the tool
func 'X', and fail with this message if the tool didn't define it. If
you use VG_TRACK(X), it wil only call it if the tool defined it.
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-07 02:11:51
|
Josef Weidendorfer wrote:
>Hi,
>
>On Saturday 05 March 2005 01:56, Julian Seward wrote:
>
>
>>It seems to me we should be very close to a 2.4.0 freeze.
>>
>>
>
>may I ask for a small set of additional tool API functions? I'm currently
>working on data structure related profiling info, and for that to be
>acceptable, I need to maintain a mapping table from address to objects. For
>static objects, I have to hook into symbol loading, and that is what the tool
>API addition is for.
>
>
This patch makes everything fail with
Tool error:
The tool you have selected is missing the function `track_new_segment',
which is required.
Nulgrind: the `impossible' happened:
Missing tool function
J
|