|
From: Julian S. <js...@ac...> - 2010-09-27 09:20:54
|
Greetings.
It's time to do a new release -- in fact, it's well overdue.
I'm proposing to make a release in 3 weeks, on Monday 18 October.
In previous releases it's been inconvenient to have to freeze the
trunk as release day draws near, so I am proposing this time to
make the 3.6 branch one week before that (11 Oct) and
stabilise/release from the branch. That means a bit more work
moving changes between branches, but I think it's worth it.
The release platforms will be: {x86,amd64,arm,ppc32,ppc64}-linux
and {x86,amd64}-darwin.
I believe the tree is in pretty good shape for a release now.
There are a number of bugs still to be resolved, but nothing
particularly critical. I'll list the ones I'd like to have fixed
in a followup message.
J
|
|
From: Bart V. A. <bva...@ac...> - 2010-09-27 10:26:54
|
On Mon, Sep 27, 2010 at 11:18 AM, Julian Seward <js...@ac...> wrote:
>
> Greetings.
>
> It's time to do a new release -- in fact, it's well overdue.
>
> I'm proposing to make a release in 3 weeks, on Monday 18 October.
> In previous releases it's been inconvenient to have to freeze the
> trunk as release day draws near, so I am proposing this time to
> make the 3.6 branch one week before that (11 Oct) and
> stabilise/release from the branch. That means a bit more work
> moving changes between branches, but I think it's worth it.
>
> The release platforms will be: {x86,amd64,arm,ppc32,ppc64}-linux
> and {x86,amd64}-darwin.
>
> I believe the tree is in pretty good shape for a release now.
> There are a number of bugs still to be resolved, but nothing
> particularly critical. I'll list the ones I'd like to have fixed
> in a followup message.
>
Hello Julian,
Can you have a look at the compiler warnings that are triggered by the VEX
changes since 3.5.0 ? One patch that fixes some of these compiler warnings
can be found here: https://bugs.kde.org/show_bug.cgi?id=247223.
Bart.
|
|
From: Christian B. <bor...@de...> - 2010-09-27 12:10:31
|
Am 27.09.2010 11:18, schrieb Julian Seward:
>
> Greetings.
>
> It's time to do a new release -- in fact, it's well overdue.
>
> I'm proposing to make a release in 3 weeks, on Monday 18 October.
Cool.
> In previous releases it's been inconvenient to have to freeze the
> trunk as release day draws near, so I am proposing this time to
> make the 3.6 branch one week before that (11 Oct) and
> stabilise/release from the branch. That means a bit more work
> moving changes between branches, but I think it's worth it.
I think it makes a lot of sense.
>
> The release platforms will be: {x86,amd64,arm,ppc32,ppc64}-linux
> and {x86,amd64}-darwin.
Given that valgrind become more and more a cross-platform tool,
I would like to ask for more review of the s390x port.
The s390x port has matured significantly - see
https://bugs.kde.org/show_bug.cgi?id=243404.
I understand that this change is too big for 3.6, but I would like
to target the following release for s390x integration.
We planned to do an updated patch against 3.6. I guess this means we
need two patches then, one against 3.6 and one against trunk after
the 3.6 release. As an alternative we could send un updated patch
on 11 Oct that matches both.
I would also like to have some feedback and code review from interested
parties and tool maintainers (e.g. what else needs to be done for
integration) and therefore updated the patches to r11383/r2046.
In addition, can architecture maintainers check that these patches dont
break anything for them. (arm, ppc, x86, amd64, darwin ...)?
Thanks
Christian
|
|
From: Florian K. <br...@ac...> - 2010-09-28 00:27:11
|
On Monday 27 September 2010 05:18:37 am Julian Seward wrote:
>
> Greetings.
>
> It's time to do a new release -- in fact, it's well overdue.
>
> I'm proposing to make a release in 3 weeks, on Monday 18 October.
> In previous releases it's been inconvenient to have to freeze the
> trunk as release day draws near, so I am proposing this time to
> make the 3.6 branch one week before that (11 Oct) and
> stabilise/release from the branch. That means a bit more work
> moving changes between branches, but I think it's worth it.
>
> The release platforms will be: {x86,amd64,arm,ppc32,ppc64}-linux
> and {x86,amd64}-darwin.
>
> I believe the tree is in pretty good shape for a release now.
> There are a number of bugs still to be resolved, but nothing
> particularly critical. I'll list the ones I'd like to have fixed
> in a followup message.
>
Julian,
would you consider including https://bugs.kde.org/show_bug.cgi?id=246888
It makes the build system more robust for those modifying the guest state
and helps new ports, too.
Thanks,
Florian
|
|
From: Julian S. <js...@ac...> - 2010-10-01 14:38:00
|
On Tuesday, September 28, 2010, Florian Krohm wrote:
> On Monday 27 September 2010 05:18:37 am Julian Seward wrote:
> > Greetings.
> >
> > It's time to do a new release -- in fact, it's well overdue.
> >
> > I'm proposing to make a release in 3 weeks, on Monday 18 October.
> > In previous releases it's been inconvenient to have to freeze the
> > trunk as release day draws near, so I am proposing this time to
> > make the 3.6 branch one week before that (11 Oct) and
> > stabilise/release from the branch. That means a bit more work
> > moving changes between branches, but I think it's worth it.
> >
> > The release platforms will be: {x86,amd64,arm,ppc32,ppc64}-linux
> > and {x86,amd64}-darwin.
> >
> > I believe the tree is in pretty good shape for a release now.
> > There are a number of bugs still to be resolved, but nothing
> > particularly critical. I'll list the ones I'd like to have fixed
> > in a followup message.
>
> Julian,
>
> would you consider including https://bugs.kde.org/show_bug.cgi?id=246888
> It makes the build system more robust for those modifying the guest state
> and helps new ports, too.
Done.
J
|
|
From: Philippe W. <phi...@sk...> - 2010-09-28 19:04:32
|
> From: "Julian Seward" <js...@ac...> > Sent: Monday, September 27, 2010 11:18 AM > I believe the tree is in pretty good shape for a release now. > There are a number of bugs still to be resolved, but nothing > particularly critical. I'll list the ones I'd like to have fixed > in a followup message. At work, we are going to evaluate the patch in http://bugs.kde.org/show_bug.cgi?id=206600 (we have a whole bunch of false possibly lost). Note that the 8 bytes LC_Extra looks cleaner/not problematic. If it works well, it looks a good candidate for 3.6.0. Also, if the patch for http://bugs.kde.org/show_bug.cgi?id=250101 (quadratic superblock fragmentation for "linear realloc" pattern) could be looked at, that would be really nice. Thanks |
|
From: Bart V. A. <bva...@ac...> - 2010-09-29 10:39:36
|
On Mon, Sep 27, 2010 at 11:18 AM, Julian Seward <js...@ac...> wrote:
>
> Greetings.
>
> It's time to do a new release -- in fact, it's well overdue.
>
> I'm proposing to make a release in 3 weeks, on Monday 18 October.
> In previous releases it's been inconvenient to have to freeze the
> trunk as release day draws near, so I am proposing this time to
> make the 3.6 branch one week before that (11 Oct) and
> stabilise/release from the branch. That means a bit more work
> moving changes between branches, but I think it's worth it.
>
> The release platforms will be: {x86,amd64,arm,ppc32,ppc64}-linux
> and {x86,amd64}-darwin.
>
> I believe the tree is in pretty good shape for a release now.
> There are a number of bugs still to be resolved, but nothing
> particularly critical. I'll list the ones I'd like to have fixed
> in a followup message.
It would be great if stack backtracing in Valgrind for code generated
by gcc 4.5 would work as good as for code generated by earlier gcc
versions. The patch attached to
https://bugs.kde.org/show_bug.cgi?id=243270 tries to address this and
looks interesting, but unfortunately there are still unresolved issues
with that patch.
Bart.
|
|
From: Vince W. <vi...@cs...> - 2010-09-30 17:38:52
|
Hello
Anyone monitoring Bugzilla might nave noticed I've been slowly adding
patches for various amd64 unhandled instructions. I thought I should
explain my rationale, as suddenly posting a bunch of fixes right before a
proposed release isn't that great an idea.
I have a large hand-crafted assembly file that I use in an attempt to
validate the hardware performance counters on various systems. It
attempts to do a pretty thorough explortaion of the amd64 instruction
space, in order to find instructions that the hardware counters miscount
(and there are a number of instructions that are miscounted).
I use DBI tools to sanity check the "known good" counts for this
benchmark. Pin and Qemu can handle it, but there's currently numerous
instructions that Valgrind can't handle (mainly because the instructions
are rare enough that gcc doesn't emit them). Since I prefer using
Valgrind to Pin or Qemu I've been slowly trying to get them all fixed,
but it takes a while. [Fixing Valgrind isn't that bad, it's coming up
with good test cases that's a pain].
The eventual goal is to maybe have the exp-bbv plugin compensate for the
overcounts so you can more easily compare to real hardware, but that's a
long term goal.
The current list of missing instructions that my program turns up (I
haven't opened bugs for all of them yet, many of them had
been noticed previously)
* Bug 246525 -- moves to/from a segment reg not working.
* Bug 252695 -- xchg r16,r16 (patch available)
* Bug 195825 -- xlatb
* Bugs 126240, 88116 -- enter instruction
* -- push of a segment register
* -- repne cmps
* Bug 143324 -- lea with 16-bit destination (patch available)
* -- fbstp
* -- fbld
* -- fcoms
* Bug 212352 -- fcoml
* -- fcomps
* Bug 126241 -- fdecstp
* -- ficoms
* -- ficoml
* -- ficomps
* -- ficompl
* Bug 126256 -- fnop
* Bug 143325 -- fnsave
* Bug 153326 -- frstor
* -- ftst
* Bugs 143323, 149838 -- fxrstor
I'm hoping the interger fixes might be ready before the 3.6 code freeze.
The floating point ones are more of a long-term project.
Vince
|
|
From: Julian S. <js...@ac...> - 2010-10-01 14:37:05
|
> Anyone monitoring Bugzilla might nave noticed I've been slowly adding > patches for various amd64 unhandled instructions. Yes, I'd been wondering about that. > but it takes a while. [Fixing Valgrind isn't that bad, it's coming up > with good test cases that's a pain]. Overall, improving instruction coverage is no bad thing, although as you say, it's the test cases that are the critical part. > I'm hoping the interger fixes might be ready before the 3.6 code freeze. > The floating point ones are more of a long-term project. (ambiguous) You mean, you are hoping to finalise a package of tests + implementations for missing integer instructions, for before the freeze? Can you file a meta-bug for this, which uses the depends-on field to reference the other bugs for the individual instructions, that you listed in your message? J |
|
From: Eric P. <eri...@or...> - 2010-10-01 19:12:44
|
Le 30/09/2010 19:23, Vince Weaver a écrit : > Hello > > Anyone monitoring Bugzilla might nave noticed I've been slowly adding > patches for various amd64 unhandled instructions. I thought I should > explain my rationale, as suddenly posting a bunch of fixes right before a > proposed release isn't that great an idea. > > I have a large hand-crafted assembly file that I use in an attempt to > validate the hardware performance counters on various systems. It > attempts to do a pretty thorough explortaion of the amd64 instruction > space, in order to find instructions that the hardware counters miscount > (and there are a number of instructions that are miscounted). > > I use DBI tools to sanity check the "known good" counts for this > benchmark. Pin and Qemu can handle it, but there's currently numerous > instructions that Valgrind can't handle (mainly because the instructions > are rare enough that gcc doesn't emit them). Since I prefer using > Valgrind to Pin or Qemu I've been slowly trying to get them all fixed, > but it takes a while. [Fixing Valgrind isn't that bad, it's coming up > with good test cases that's a pain]. > > The eventual goal is to maybe have the exp-bbv plugin compensate for the > overcounts so you can more easily compare to real hardware, but that's a > long term goal. > > The current list of missing instructions that my program turns up (I > haven't opened bugs for all of them yet, many of them had > been noticed previously) > > * Bug 246525 -- moves to/from a segment reg not working. > * Bug 252695 -- xchg r16,r16 (patch available) > * Bug 195825 -- xlatb > * Bugs 126240, 88116 -- enter instruction > * -- push of a segment register > * -- repne cmps > * Bug 143324 -- lea with 16-bit destination (patch available) > * -- fbstp > * -- fbld > * -- fcoms > * Bug 212352 -- fcoml > * -- fcomps > * Bug 126241 -- fdecstp > * -- ficoms > * -- ficoml > * -- ficomps > * -- ficompl > * Bug 126256 -- fnop > * Bug 143325 -- fnsave > * Bug 153326 -- frstor > * -- ftst > * Bugs 143323, 149838 -- fxrstor > > for the sake of record, some of those fixes are also needed to run valgrind on Wine on amd64 to list a few: move from/to seg, push/pop seg, fxrstor those which are not listed here: push eflags, iret I have dirty work for all of those (wine/amd64 does work on valgind/amd64), that also needs some cleanup not sure I'll have time to do it before vg3.6 A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams) |
|
From: Vince W. <vi...@cs...> - 2010-10-06 22:22:53
|
On Fri, 1 Oct 2010, Eric Pouech wrote: > for the sake of record, some of those fixes are also needed to run > valgrind on Wine on amd64 > to list a few: move from/to seg, push/pop seg, fxrstor > those which are not listed here: push eflags, iret as Julian said, could you file bugs for those? Then I can link them to the "amd64 missing instructions". > I have dirty work for all of those (wine/amd64 does work on > valgind/amd64), that also needs some cleanup > not sure I'll have time to do it before vg3.6 maybe you can post those even if messy, they would be handy to have even if not completely finished. Vince |
|
From: Julian S. <js...@ac...> - 2010-10-04 20:42:32
|
On Friday, October 01, 2010, Eric Pouech wrote: > I have dirty work for all of those (wine/amd64 does work on > valgind/amd64), that also needs some cleanup > not sure I'll have time to do it before vg3.6 At least file a bug report so there's a single place to look for valgrind support patches for Wine/AMD64. |
|
From: Eric P. <eri...@or...> - 2010-10-09 12:09:28
|
Le 04/10/2010 22:39, Julian Seward a écrit : > On Friday, October 01, 2010, Eric Pouech wrote: > > >> I have dirty work for all of those (wine/amd64 does work on >> valgind/amd64), that also needs some cleanup >> not sure I'll have time to do it before vg3.6 >> > At least file a bug report so there's a single place to look > for valgrind support patches for Wine/AMD64. > > > > done as # *Bug 253657* <https://bugs.kde.org/show_bug.cgi?id=253657> I thought I had preliminary work on descriptor table & segmented address support, but couldn't find it back :-( anyway this part (segments register management) is now is safe place ;-) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams) |
|
From: Vince W. <vi...@cs...> - 2010-10-06 22:21:17
|
On Fri, 1 Oct 2010, Julian Seward wrote: > > I'm hoping the interger fixes might be ready before the 3.6 code freeze. > > The floating point ones are more of a long-term project. > > (ambiguous) You mean, you are hoping to finalise a package of tests + > implementations for missing integer instructions, for before the freeze? yes, though as I dig deeper into some of the missing instructions (especially the ones that are segment-related... what a mess) it looks unlikely I'll be able to get there. I'm working on it, but unfortunately this work is only tangentially related to my actual job. > Can you file a meta-bug for this, which uses the depends-on field to > reference the other bugs for the individual instructions, that you listed > in your message? Hmmm I tried that (as you probably saw) with bug https://bugs.kde.org/show_bug.cgi?id=253451 But my bugzilla skills are lacking and I somehow couldn't figure out how to get the Depends-on attribute to let me add dependencies. Vince |
|
From: Vince W. <vi...@cs...> - 2010-10-06 22:26:49
|
I have an qeustion about bug https://bugs.kde.org/show_bug.cgi?id=211499 This involves creating a --vex-native-cpuid=yes flag so that native cpuid info is reported. My new job is working for the PAPI perf counter group, and this fix is needed for Valgrind to do anything useful with various perf counter tools (otherwise VEX reports a CPU different than the actual one running, so the perf_events related syscalls send invalid counter settings for the wrong CPU type and thus none of the tools work). Is there any possibility of a patch like this getting in? If so I can work on cleaning it up so it applies to current SVN. Vince |
|
From: Nicholas N. <n.n...@gm...> - 2010-10-07 01:31:38
|
On Wed, Oct 6, 2010 at 3:19 PM, Vince Weaver <vi...@cs...> wrote: > On Fri, 1 Oct 2010, Julian Seward wrote: > >> Can you file a meta-bug for this, which uses the depends-on field to >> reference the other bugs for the individual instructions, that you listed >> in your message? > > Hmmm I tried that (as you probably saw) with bug > https://bugs.kde.org/show_bug.cgi?id=253451 > But my bugzilla skills are lacking and I somehow couldn't figure out how > to get the Depends-on attribute to let me add dependencies. It's easy, just modify the "depends on" field (you need to be logged in, of course). It's a comma separated list of bug numbers. And note that "blocks" and "depends on" are inverse relations -- if you mark bug A as depending on bug B, bug B will be auto-marked as blocking bug A. Nick |
|
From: Vince W. <vi...@cs...> - 2010-10-07 21:59:20
|
On Wed, 6 Oct 2010, Nicholas Nethercote wrote: > It's easy, just modify the "depends on" field (you need to be logged > in, of course). It's a comma separated list of bug numbers. And note > that "blocks" and "depends on" are inverse relations -- if you mark > bug A as depending on bug B, bug B will be auto-marked as blocking bug > A. I must be doing something wrong. I'm logged in, I pick a bug (say https://bugs.kde.org/show_bug.cgi?id=253451 ) And at the bottom there's some text saying "Depends on:", but there's no text entry field and no way to modify it as far as I can tell. I tried a few different browsers just to make sure it wasn't some weird browser/html issue. Vince |
|
From: Nicholas N. <n.n...@gm...> - 2010-10-10 22:41:24
|
On Fri, Oct 8, 2010 at 8:57 AM, Vince Weaver <vi...@cs...> wrote: > On Wed, 6 Oct 2010, Nicholas Nethercote wrote: > >> It's easy, just modify the "depends on" field (you need to be logged >> in, of course). It's a comma separated list of bug numbers. And note >> that "blocks" and "depends on" are inverse relations -- if you mark >> bug A as depending on bug B, bug B will be auto-marked as blocking bug >> A. > > I must be doing something wrong. I'm logged in, I pick a bug > (say https://bugs.kde.org/show_bug.cgi?id=253451 ) > > And at the bottom there's some text saying "Depends on:", but there's > no text entry field and no way to modify it as far as I can tell. > I tried a few different browsers just to make sure it wasn't some weird > browser/html issue. You're definitely logged in? I don't see the text box if I'm not logged in. If you are... I wonder if there's some thing where I have higher privileges than you. I wouldn't have thought depends relations would require a high privilege, though. Nick |
|
From: Vince W. <vi...@cs...> - 2010-10-12 02:12:48
|
On Mon, 11 Oct 2010, Nicholas Nethercote wrote: > > You're definitely logged in? I don't see the text box if I'm not logged in. Definitely logged in. > If you are... I wonder if there's some thing where I have higher > privileges than you. I wouldn't have thought depends relations would > require a high privilege, though. Maybe you can only modify it if you are the asignee? I can't test that without filing a fake exp-bbv report though. I've been googling about this trying to figure out if it's a problem on my end, unfortunately "Depends on" is a lousy set of search terms. I gather that usually bugzilla is configured so that the reporter of a bug can edit depends on info, but maybe the kde bugzilla is set up differently... Vince |
|
From: Ed M. <em...@fr...> - 2010-10-21 02:34:26
|
On Mon, Sep 27, 2010 at 11:18:37AM +0200, Julian Seward wrote: > > Greetings. > > It's time to do a new release -- in fact, it's well overdue. We'll get started on updating the FreeBSD port to 3.6 soon, and reference the patch set from the Bugzilla entry for FreeBSD support once it's ready. http://bugs.kde.org/show_bug.cgi?id=208531 -Ed |