|
From: Julian S. <js...@ac...> - 2005-08-08 16:09:55
|
It's great we finally got 3.0.0 out the door. Here are some thoughts about What Next. I'd like to do a 3.0.1 relatively soon, to fix easily-fixed breakage in 3.0.0. Given that the most obvious breakage in 3.0.0 is likely to get reported quickly, emitting 3.0.1 some time in the last week of August would get a stabler 3.0.X to users relatively soon. Thinking about 3.1, I'd like to ship two things which didn't make 3.0: - A rewritten address space manager, which will finally make the thing work properly on 64-bit platforms, and should provide a better base for porting to non-Linux OSs. - Support for 32-bit PowerPC-Linux. The code is already in there but has various problems which mean it isn't usable at the moment. It would be nice to ship in 3.1 fixes for some of the more ominous looking problems in 3.0. Currently the only one I can think of is 110205 (sigcancel handler fails: stack unwinds into valgrind). Some other lines of enquiry which would be good to at least consider for 3.1 are: - reinstate, or delete, Addrcheck. This could involve a study of the compressed-Vbit-representation problem. - review the thread-modelling stuff, so that at a minimum the pthread-API-abuse checks can be reinstated, and, ultimately, Helgrind can be fixed up. I'd like to have 3.1.0 out within the next three months if that proves viable. Taking (another) leaf from the Gcc Way Of Doing Things, that would mean at most 2 months of new feature hacking followed by a 1-month stabilisation period. Generally speaking, as we move on from 3.0, the emphasis changes from dealing with different instruction sets to making the system level simulation more portable, so as to improve the possibility of porting away from Linux. A side effect of that is to continue the modularisation/restructuring of the code base that started a couple of months back. Comments, thoughts, other stuff that needs doing? J |
|
From: Nicholas N. <nj...@cs...> - 2005-08-08 18:32:27
|
On Mon, 8 Aug 2005, Julian Seward wrote: > I'd like to do a 3.0.1 relatively soon, to fix easily-fixed > breakage in 3.0.0. Sounds good. > - A rewritten address space manager, which will finally make > the thing work properly on 64-bit platforms, and should > provide a better base for porting to non-Linux OSs. Yes! A lot of the outstanding problems and bugs are related to this. > - reinstate, or delete, Addrcheck. This could involve a > study of the compressed-Vbit-representation problem. > > - review the thread-modelling stuff, so that at a minimum the > pthread-API-abuse checks can be reinstated, and, ultimately, > Helgrind can be fixed up. Both would be good, I think it will come down to whether anyone has time to look at them; they're both sizeable projects. > I'd like to have 3.1.0 out within the next three months if that > proves viable. Taking (another) leaf from the Gcc Way Of Doing > Things, that would mean at most 2 months of new feature hacking > followed by a 1-month stabilisation period. Also sounds good. > Generally speaking, as we move on from 3.0, the emphasis changes > from dealing with different instruction sets to making the system > level simulation more portable, so as to improve the possibility > of porting away from Linux. A side effect of that is to continue > the modularisation/restructuring of the code base that started > a couple of months back. Again, yes, sounds good. N |
|
From: Maurice v. d. P. <gri...@ge...> - 2005-08-09 17:34:52
|
On Mon, Aug 08, 2005 at 08:21:00PM +0100, Julian Seward wrote: > - A rewritten address space manager, which will finally make=20 > the thing work properly on 64-bit platforms, and should > provide a better base for porting to non-Linux OSs. Is this new code also meant to allow PIE builds? Not that I'm a fan of building with PIE, but at the moment I have no way of disabling it other than patching configure. The reason for this is that we have compiler profiles that default to PIE and actually need a flag to disable it. Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Tom H. <to...@co...> - 2005-08-09 18:17:44
|
In message <200...@kf...>
Maurice van der Pot <gri...@ge...> wrote:
> On Mon, Aug 08, 2005 at 08:21:00PM +0100, Julian Seward wrote:
> > - A rewritten address space manager, which will finally make
> > the thing work properly on 64-bit platforms, and should
> > provide a better base for porting to non-Linux OSs.
>
> Is this new code also meant to allow PIE builds?
It will make PIE builds unnecessary so they will presumably go away.
> Not that I'm a fan of building with PIE, but at the moment I have no way
> of disabling it other than patching configure. The reason for this is
> that we have compiler profiles that default to PIE and actually need
> a flag to disable it.
I don't think it will matter if you build with -fpie - if you haven't
use --enable-pie then valgrind will be loaded at a fixed address even
if you happened to build with -fpie and there won't be any problems.
The only downside is a possible slight slowdown from the fact that you
are using position independent code when don't have to.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Maurice v. d. P. <gri...@ge...> - 2005-08-09 22:17:52
|
On Tue, Aug 09, 2005 at 07:16:30PM +0100, Tom Hughes wrote: > I don't think it will matter if you build with -fpie - if you haven't > use --enable-pie then valgrind will be loaded at a fixed address even > if you happened to build with -fpie and there won't be any problems. Right now if I build 3.0.0 with a gcc that defaults to pie but I don't=20 specify --enable-pie, it exits at startup with "executable range is=20 outside acceptable range". Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Tom H. <to...@co...> - 2005-08-09 22:47:36
|
In message <200...@kf...>
Maurice van der Pot <gri...@ge...> wrote:
> On Tue, Aug 09, 2005 at 07:16:30PM +0100, Tom Hughes wrote:
> > I don't think it will matter if you build with -fpie - if you haven't
> > use --enable-pie then valgrind will be loaded at a fixed address even
> > if you happened to build with -fpie and there won't be any problems.
>
> Right now if I build 3.0.0 with a gcc that defaults to pie but I don't
> specify --enable-pie, it exits at startup with "executable range is
> outside acceptable range".
Wierd. Without --enable-pie stage2 should be linked with a fixed
base address that is certainly within the acceptable range. CAn you
give the full message (with the addresses).
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-10 04:08:39
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> - review the thread-modelling stuff, so that at a minimum the
> pthread-API-abuse checks can be reinstated, and, ultimately,
> Helgrind can be fixed up.
The critical issue here is to get the function wrapping stuff working
again, which probably needs some VEX work. I did look at it last week
and the old code relied on the UCode translator to insert calls to the
pre and post function handlers.
Once function wrapping is working enabling the existing thread modelling
should be fairly simple and then we can try and improve it and make it
more robust.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|