New branch for Fedora 11 merges

New branch for Fedora 11 merges

[Rick Moseley]

Hi all,

I have created a new, improved branch for the Fedora 11 merges named: 
archer-rmoseley-f11-merge.  Somehow I seem to have horked up the old 
branch, archer-rmoseley-fedora-merge, so now the new branch is the one 
that should be used.

Here are the branches that are merged in the new branch:

archer-tromey-python
archer-sergio-catch-syscall
archer-tromey-delayed-symfile
Phil's patch for exceptions
archer-tromey-charset


Is anyone else's branch ready to be merged?  I was saving your branches 
for last Jan("vla" and "misc") just in case I ran out of time before my 
last day.  I figured you would probably be able to merge those best 
since they are yours.  However if no one else is ready to have their 
branch merged, I can go ahead and do the "vla" one if you like.

Thanks,

Rick

Re: New branch for Fedora 11 merges

[Sami Wagiaalla]

> Is anyone else's branch ready to be merged?

I have merged my branch archer-swagiaal-using-directive into Keiths' 
branch archer-keiths-expr-cumulative, and resolved conflicts. If Keith 
is done with archer-keiths-expr-cumulative, it is ready to go.

Thanks
   Sami

Re: New branch for Fedora 11 merges

[Keith Seitz]

Sami Wagiaalla wrote:
> 
>> Is anyone else's branch ready to be merged?
> 
> I have merged my branch archer-swagiaal-using-directive into Keiths' 
> branch archer-keiths-expr-cumulative, and resolved conflicts. If Keith 
> is done with archer-keiths-expr-cumulative, it is ready to go.

Have you run the branch through the test suite before your commit? I 
updated my copy of the branch today and picked up your using directive 
changes, and now I'm seeing a bunch of new failures (38 new failures) -- 
all seem to be failing the same way.

Here's an example (bs15503.exp):
./gdb -nx -q testsuite/gdb.cp/bs15503
(gdb) b main
../../archer/gdb/utils.c:1174: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

Can you verify that your copy of the branch is okay?

Keith

Re: New branch for Fedora 11 merges

[Keith Seitz]

Keith Seitz wrote:

> Can you verify that your copy of the branch is okay?

Don't bother: the branch is definitely foobared by one of the "using 
directive" commits.

I have only chased this down a little, but I just cannot imagine how 
this is supposed to work:

In read_func_scope (dwarf2read.c), if the name is not set (in this case 
it is) or dwarf2_read_pc_bounds fails (which it does), the code calls 
explore_abstract_origin with the address of a locally uninitialized 
variable (die_children). This is then simply dereferenced in 
explore_abstract_origin, and consequently passed to xmalloc, which 
attempts to allocate over 4GB in my case...

Can you double-check that all the necessary bits of your patches got 
into the branch properly?

Keith

PS. I notice that quite a few of the "using directive" patches are 
malformed. Could you please update the patches to use the GNU coding 
standard?

Re: New branch for Fedora 11 merges

[Jan Kratochvil]

On Tue, 17 Feb 2009 17:23:01 +0100, Sami Wagiaalla wrote:
>
>> Is anyone else's branch ready to be merged?
>
> I have merged my branch archer-swagiaal-using-directive into Keiths'  
> branch archer-keiths-expr-cumulative, and resolved conflicts. If Keith  
> is done with archer-keiths-expr-cumulative, it is ready to go.

IMO archer-swagiaal-using-directive and archer-keiths-expr-cumulative are not
based one on the other and the functionality of each of the branches can be
fully exploited without the code of the other branch.  Or am I wrong?


If you would like to help with the merging please create a new merged branch
(something like archer-swagiaal-cxx-merge) tracking both the branches
archer-swagiaal-using-directive and archer-keiths-expr-cumulative.

Merging together the base branches of unrelated functionalities creates more
work during later splitting for reviews, regression analysis on updates,
merges etc.


Also please if you get some parts of the branch (as happened multiple times
for archer-tromey-python) accepted for FSF GDB please git-revert (or just
unpatch/commit) that part and freshly merge it with origin/master (after its
update from gdb/master).  Otherwise it is a lot of later looking up which
variant is the more recent - if it got updated during the FSF GDB discussions
before it got accepted for FSF GDB or if it got updated in Archer since the
FSF GDB accept.


To advocate myself on the recently created merge branch:
archer-jankratochvil-python - Merge of "archer-tromey-python"
                              with "archer-jankratochvil-type-refcount" 
is IMO useful to merge as both the [python] and [vla] branches require the
[type-refcount] functionality.  [vla] has been already based on latest
[type-refcount] while [python] was still using the base part of
[type-refcount] originally written by Tom and sufficient for [python] (but not
sufficient for [vla]).



Regards,
Jan

Re: New branch for Fedora 11 merges

[Keith Seitz]

Jan Kratochvil wrote:

> IMO archer-swagiaal-using-directive and archer-keiths-expr-cumulative are not
> based one on the other and the functionality of each of the branches can be
> fully exploited without the code of the other branch.  Or am I wrong?

The big concern that I have about using separate branches is that both 
Sami and I are touching the same parts of GDB (and not superficially, 
either), and we may introduce patches on separate branches which may 
interfere with each other later when merged.

I've already run into this with my two expressions-related branches, and 
I believe that Sami has also run into this when he merged into the 
expr-cumulative branch from his own branch. I foresaw this happening, 
and that's why I moved to committing all my expressions work into a 
single, unified branch in the last couple of weeks.

Yes, it will be a huge amount of work to extract small, digestible 
pieces for submitting upstream. Then again, when it comes to upstream 
GDB, everything is a huge amount of work anyway. It's part of the price 
we pay for the decisions we've made.

> Also please if you get some parts of the branch (as happened multiple times
> for archer-tromey-python) accepted for FSF GDB please git-revert (or just
> unpatch/commit) that part and freshly merge it with origin/master (after its
> update from gdb/master).

That's a good point: I'd never have thought of that. Once again, this is 
an artifact of our development model, which appears (to me) to have its 
problems. [Hint: Are we going to have to allocate resources for one 
person to continually merge "features/fixes" (branches) into a "release 
branch"?]

Keith

Re: New branch for Fedora 11 merges

[Sami Wagiaalla]

> In read_func_scope (dwarf2read.c), if the name is not set (in this case 
> it is) or dwarf2_read_pc_bounds fails (which it does), the code calls 
> explore_abstract_origin with the address of a locally uninitialized 
> variable (die_children). This is then simply dereferenced in 
> explore_abstract_origin, and consequently passed to xmalloc, which 
> attempts to allocate over 4GB in my case...
> 

I introduced this problem earlier when i was trying to resolve a 
conflict that I had with a patch of Jan's. 
1de38657622396795ce681e64b03fb74e81e6c3d vs 
60eb8684d0d85d0884aca7a2f013e5eb16a51d47

I'll check in a fix for this. The issue is that sometimes a function Die 
might now have high/low pc tags but it has an abstract origin tag 
pointing to useful namespace information.

> PS. I notice that quite a few of the "using directive" patches are 
> malformed. Could you please update the patches to use the GNU coding 
> standard?

Will do.

Re: New branch for Fedora 11 merges

[Jan Kratochvil]

On Wed, 25 Feb 2009 18:32:54 +0100, Keith Seitz wrote:
> The big concern that I have about using separate branches is that both  
> Sami and I are touching the same parts of GDB (and not superficially,  
> either), and we may introduce patches on separate branches which may  
> interfere with each other later when merged.

Another possibility I am used to (well because Fedora/quilt work exactly this
way) is just to base the branch on top of the other branch.  But sure it is
something in between the fully separate and fully merged development, in both
the pros and cons - it is still separable but the top branch is not
submittable as is separately etc.


> I've already run into this with my two expressions-related branches, and  
> I believe that Sami has also run into this when he merged into the  
> expr-cumulative branch from his own branch.

The positive income is that once the problematic parts get merged the
continuous incremental development may +/- get imported the the merged-branch
for free.  But understood more significant changes still conflict.


I may be biased by the separate pathes of Fedora; AFAIK Debian uses a single
merged vendor patch for each package.


> [Hint: Are we going to have to allocate resources for one  person to
> continually merge "features/fixes" (branches) into a "release  branch"?]

Please note I do not find this as too much a problem of the merging effort.
It is more a problem of the disconnection from the valuable community testing
- the end users.  Implications of an end user problem get less and less
related to the original "blue skue" development branch as the problem may be
related to the merging glues no longer reproducible on the original branch.

Still to find out where the problem comes from means fixing it which means to
fix it first in the merged branch and later - sometimes completely differently
- in the "blue sky" original development branch.

This is the visible disadvantage of the Fedora fork from FSF GDB negatively
affecting both the projects.  Trying to prevent happending this again even
with Fedora vs. Archer.


It may be seen as I am contradicting myself above by both parts of the mail
but I hope it makes sense.


Regards,
Jan

Re: New branch for Fedora 11 merges

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> Also please if you get some parts of the branch (as happened
Jan> multiple times for archer-tromey-python) accepted for FSF GDB
Jan> please git-revert (or just unpatch/commit) that part and freshly
Jan> merge it with origin/master (after its update from gdb/master).
Jan> Otherwise it is a lot of later looking up which variant is the
Jan> more recent - if it got updated during the FSF GDB discussions
Jan> before it got accepted for FSF GDB or if it got updated in Archer
Jan> since the FSF GDB accept.

Pardon my git ignorance here, but why doesn't "git merge master", plus
fixing up the conflicts, also have the desired effect?

The issue with revert is that, at least on that branch, the commits
don't always correspond to upstream patches, because we're submitting
things in a different order than we write them.

Tom

Re: New branch for Fedora 11 merges

[Jan Kratochvil]

On Wed, 25 Feb 2009 23:32:38 +0100, Tom Tromey wrote:
> Pardon my git ignorance here, but why doesn't "git merge master", plus
> fixing up the conflicts, also have the desired effect?

In general I agree; just I was using git-revert in archer-jankratochvil-misc
so far.

Countercase:

If I change func1() and func2() in GIT, post it for FSF GDB, func1() change is
dropped during the discussion as needless, func2() gets accepted.

"git merge master" will excessively keep func1() modified in the GIT branch.

I understand it may happen only very rarely.


> The issue with revert is that, at least on that branch, the commits
> don't always correspond to upstream patches, because we're submitting
> things in a different order than we write them.

I agree the submitted part may be only a part of some GIT commit.  Just if it
is possible I find it more clean - if I apply a new patch I should remove
first the old patch as otherwise I will definitely have to resolve a conflict.


Regards,
Jan

Re: New branch for Fedora 11 merges

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:

Keith> Yes, it will be a huge amount of work to extract small, digestible
Keith> pieces for submitting upstream. Then again, when it comes to upstream
Keith> GDB, everything is a huge amount of work anyway. It's part of the
Keith> price we pay for the decisions we've made.

If it is cheaper to do things some other way, or gets us better
results, we can change how we operate.  I'm adamant about a set of
values (e.g., openness & transparency) and a set of outcomes (quality,
performance, meeting users' needs), but not so much any particular way
of getting there.

Keith> Once again, this is an artifact of our development model, which
Keith> appears (to me) to have its problems. [Hint: Are we going to
Keith> have to allocate resources for one person to continually merge
Keith> "features/fixes" (branches) into a "release branch"?]

Yeah, we'll need someone to do the merge whenever we're in a window
for a release, which probably means every 6 months.  Some of this work
will be shared: the master->feature merges before the big release
merges, in particular.

I do think we should be submitting things upstream as we are able,
because this will keep a lid on our costs over the long haul.  "As we
are able" just means when a feature are ready and when we have a
convenient hole in our schedule to do the work of submitting.

Tom

Re: New branch for Fedora 11 merges

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> I may be biased by the separate pathes of Fedora; AFAIK Debian
Jan> uses a single merged vendor patch for each package.

FWIW, I've been liking the current approach.  Based on my experience
with master->python merges, git makes merging very easy, and I think
merging the features into one big branch makes it harder to prep a
feature for submission.

Jan> It is more a problem of the disconnection from the valuable
Jan> community testing - the end users.
[...]
Jan> This is the visible disadvantage of the Fedora fork from FSF GDB
Jan> negatively affecting both the projects.  Trying to prevent
Jan> happending this again even with Fedora vs. Archer.

Yeah, I agree.  I'd like us not to make this situation worse.  At the
same time, I still think that developing a feature on a branch makes
for a very nice way of working.

I don't really know how to thread the needle here.  Are we not
submitting things upstream enough?  My impression is that we are doing
that as fast as we're able; there aren't many features that are
complete and unsubmitted.  In fact, maybe the only one is
archer-pmuldoon-exception-rewind.

Maybe we should spend some time sending Fedora patches upstream?  I am
happy to work on this; I just tend to prioritize development because
it is more fun :-}

One way I view our development approach is that we are just doing what
the other gdb developers do, it is just that we are doing it all in
public.  That is, we share all the intermediate steps of our work
instead of just sharing the final patch.

Anyway ... I am glad you guys brought this up.  I'd like to hear any
thoughts anybody has on this topic.  As far as I'm concerned, we can
make any change that we agree is helpful.  Send suggestions.

Tom

Re: New branch for Fedora 11 merges

[Thiago Jung Bauermann]

El mié, 25-02-2009 a las 23:41 +0100, Jan Kratochvil escribió:
> On Wed, 25 Feb 2009 23:32:38 +0100, Tom Tromey wrote:
> > Pardon my git ignorance here, but why doesn't "git merge master", plus
> > fixing up the conflicts, also have the desired effect?
> 
> In general I agree; just I was using git-revert in archer-jankratochvil-misc
> so far.
> 
> Countercase:
> 
> If I change func1() and func2() in GIT, post it for FSF GDB, func1() change is
> dropped during the discussion as needless, func2() gets accepted.
> 
> "git merge master" will excessively keep func1() modified in the GIT branch.
> 
> I understand it may happen only very rarely.

When I post python patches upstream and rework them based on review
comments, I always make the changes both in the python branch and in the
patch I'm submitting, to avoid exactly that problem. In fact, most of
the time, I do the rework in the branch and then cherry-pick the commit
to the branch with the python patches.

If there's a merge conflict because upstream is different than the
python branch, then I probably screwed up somewhere. But I try to be
careful with this.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

[expr-cumulative] + [using-directive] status [Re: New branch for Fedora 11 merges]

[Jan Kratochvil]

On Wed, 25 Feb 2009 02:32:28 +0100, Keith Seitz wrote:
> Sami Wagiaalla wrote:
>>> Is anyone else's branch ready to be merged?
>>
>> I have merged my branch archer-swagiaal-using-directive into Keiths'  
>> branch archer-keiths-expr-cumulative, and resolved conflicts. If Keith  
>> is done with archer-keiths-expr-cumulative, it is ready to go.
>
> Have you run the branch through the test suite before your commit? I  
> updated my copy of the branch today and picked up your using directive  
> changes, and now I'm seeing a bunch of new failures (38 new failures) --  

On archer-keiths-expr-cumulative HEAD 756fe0377686543d8e0e3f84f77f06f7a4bc17a7
I see also a lot of FAILures, particularly on:
gdb.cp/breakpoint.exp
gdb.cp/bs15503.exp
gdb.cp/cplusfuncs.exp
gdb.cp/exception.exp 
gdb.cp/formatted-ref.exp
gdb.cp/member-ptr.exp
gdb.cp/templates.exp

Also the branch needs an update from master - it is now 6.8.50.20090127-cvs.

Please tell me which subparts are ready for the merge for Fedora-11.  As it
will start to have Fedora betatesters no completely formally new code should
go in after the Fedora-11 Feature Freeze on 2009-03-03.


archer-keiths-realcpp-test does not build on Fedora 10 x86_64:
gdb.cp/realcpp.cc:225: error: ‘operator new’ takes type ‘size_t’ (‘long unsigned int’) as first parameter
gdb.cp/realcpp.cc:231: error: ‘operator new’ takes type ‘size_t’ (‘long unsigned int’) as first parameter


Thanks,
Jan

Re: New branch for Fedora 11 merges

[Sami Wagiaalla]

Sami Wagiaalla wrote:
> 
>> In read_func_scope (dwarf2read.c), if the name is not set (in this 
>> case it is) or dwarf2_read_pc_bounds fails (which it does), the code 
>> calls explore_abstract_origin with the address of a locally 
>> uninitialized variable (die_children). This is then simply 
>> dereferenced in explore_abstract_origin, and consequently passed to 
>> xmalloc, which attempts to allocate over 4GB in my case...
>>
> 
> I introduced this problem earlier when i was trying to resolve a 
> conflict that I had with a patch of Jan's. 
> 1de38657622396795ce681e64b03fb74e81e6c3d vs 
> 60eb8684d0d85d0884aca7a2f013e5eb16a51d47
> 
> I'll check in a fix for this. The issue is that sometimes a function Die 
> might now have high/low pc tags but it has an abstract origin tag 
> pointing to useful namespace information.
> 

I have check in a fix for this.

[keiths-expr-cumulative] Regressions [Re: New branch for Fedora 11 merges]

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]

On Fri, 27 Feb 2009 23:03:26 +0100, Sami Wagiaalla wrote:
> Sami Wagiaalla wrote:
>> I introduced this problem earlier when i was trying to resolve a  
>> conflict that I had with a patch of Jan's.  
>> 1de38657622396795ce681e64b03fb74e81e6c3d vs  
>> 60eb8684d0d85d0884aca7a2f013e5eb16a51d47
>>
>> I'll check in a fix for this. The issue is that sometimes a function 
>> Die might now have high/low pc tags but it has an abstract origin tag  
>> pointing to useful namespace information.
>
> I have check in a fix for this.

[archer-keiths-expr-cumulative] 3513c57475d20e65ac2fb2be097227011c4b8b5a


It still has a lot of regressions (tried archer-keiths-expr-cumulative) like:
	info function operator\*(^M
	memory clobbered past end of allocated block^M
	FAIL: gdb.cp/cplusfuncs.exp: info function for "operator%(" (timeout)
(at least on F10.x86_64 using mcheck: LDFLAGS="-lmcheck" ./configure...).

Possible quick fix is attached (not checked-in) - my code moved into
explore_abstract_origin() needs to know (the `die_children' count is only read)
the number of children DIEs - to allocate appropriately sized array.


Unfortunately even after this attached fix the branch is FAILing on:
+FAIL: gdb.cp/namespace-using.exp: print _a
+FAIL: gdb.cp/namespace-using.exp: print x

* Every test name should be unique - this is the reason the names exist.
  You do not follow it.
* You use `send_gdb' without waiting on the response of each command - some
  wait on "$gdb_prompt $".  The waiting can be usually done by `gdb_test', in
  more complicated cases by `gdb_test_multiple'.  Otherwise the results get
  random as dejagnu is not in sync with the GDB output.
* There are even specific library functions `gdb_breakpoint' and
  `gdb_continue_to_breakpoint' which you use but only sometimes.
* Pattern start `"\\$\[0-9\].* =' should have been more `"\\$\[0-9\]+ ='
  (although it is also considered safe to use just `=').


There is now a change
KFAIL: gdb.cp/templates.exp: constructor breakpoint (PRMS: gdb/1062)
->
FAIL: gdb.cp/templates.exp: constructor breakpoint
although IMO the current output should be considered as PASS now.


The branch is still pretty old 6.8.50.20090127-cvs and while I would update it
but as it currently has regressions I cannot verify I would not break it.



Regards,
Jan

[-- Attachment #2: archer-keiths-expr-cumulative-memfix.patch --]
[-- Type: text/plain, Size: 625 bytes --]

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 3e17767..a9251cb 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -3317,6 +3317,12 @@ read_func_scope (struct die_info *die, struct dwarf2_cu *cu)
   if (name == NULL || !dwarf2_get_pc_bounds (die, &lowpc, &highpc, cu, NULL)){
     /* explore abstract origins if present. They might contain useful information
      such as import statements. */
+    child_die = die->child;
+    while (child_die && child_die->tag)
+      {
+	child_die = sibling_die (child_die);
+	die_children++;
+      }
     explore_abstract_origin(die, cu, &die_children);
     return;
   }

Re: [keiths-expr-cumulative] Regressions [Re: New branch for Fedora 11 merges]

[Sami Wagiaalla]

Jan Kratochvil wrote:
> On Fri, 27 Feb 2009 23:03:26 +0100, Sami Wagiaalla wrote:
>> Sami Wagiaalla wrote:
>>> I introduced this problem earlier when i was trying to resolve a  
>>> conflict that I had with a patch of Jan's.  
>>> 1de38657622396795ce681e64b03fb74e81e6c3d vs  
>>> 60eb8684d0d85d0884aca7a2f013e5eb16a51d47
>>>
>>> I'll check in a fix for this. The issue is that sometimes a function 
>>> Die might now have high/low pc tags but it has an abstract origin tag  
>>> pointing to useful namespace information.
>> I have check in a fix for this.
> 
> [archer-keiths-expr-cumulative] 3513c57475d20e65ac2fb2be097227011c4b8b5a
> 
> 
> It still has a lot of regressions (tried archer-keiths-expr-cumulative) like:
> 	info function operator\*(^M
> 	memory clobbered past end of allocated block^M
> 	FAIL: gdb.cp/cplusfuncs.exp: info function for "operator%(" (timeout)
> (at least on F10.x86_64 using mcheck: LDFLAGS="-lmcheck" ./configure...).
> 
> Possible quick fix is attached (not checked-in) - my code moved into
> explore_abstract_origin() needs to know (the `die_children' count is only read)
> the number of children DIEs - to allocate appropriately sized array.
> 

I have committed your patch. Thanks.

> 
> Unfortunately even after this attached fix the branch is FAILing on:
> +FAIL: gdb.cp/namespace-using.exp: print _a
> +FAIL: gdb.cp/namespace-using.exp: print x
> 

Are these the only regressions left ?

> * Every test name should be unique - this is the reason the names exist.
>   You do not follow it.
> * You use `send_gdb' without waiting on the response of each command - some
>   wait on "$gdb_prompt $".  The waiting can be usually done by `gdb_test', in
>   more complicated cases by `gdb_test_multiple'.  Otherwise the results get
>   random as dejagnu is not in sync with the GDB output.
> * There are even specific library functions `gdb_breakpoint' and
>   `gdb_continue_to_breakpoint' which you use but only sometimes.
> * Pattern start `"\\$\[0-9\].* =' should have been more `"\\$\[0-9\]+ ='
>   (although it is also considered safe to use just `=').
> 

Thanks for the pointers. I have made the changes and committed the patch.

> 
> There is now a change
> KFAIL: gdb.cp/templates.exp: constructor breakpoint (PRMS: gdb/1062)
> ->
> FAIL: gdb.cp/templates.exp: constructor breakpoint
> although IMO the current output should be considered as PASS now.
> 
> 
> The branch is still pretty old 6.8.50.20090127-cvs and while I would update it
> but as it currently has regressions I cannot verify I would not break it.
> 

I will update if there are no regressions now.

> 
> 
> Regards,
> Jan
> 

Re: [keiths-expr-cumulative] Regressions

[Jan Kratochvil]

On Mon, 02 Mar 2009 16:39:17 +0100, Sami Wagiaalla wrote:
>> Unfortunately even after this attached fix the branch is FAILing on:
>> +FAIL: gdb.cp/namespace-using.exp: print _a
>> +FAIL: gdb.cp/namespace-using.exp: print x
>
> Are these the only regressions left ?

There is also that `constructor breakpoint' FAIL although assuming it is not
from you.  And feel free to run the testsuite yourself and compare the gdb.sum
files from unpatched GDB.  :-)


> Thanks for the pointers. I have made the changes and committed the patch.

c7c96c12054b0089c813555d72c60e8cdaa56946 looks OK to me, thanks.


> I will update if there are no regressions now.

I already had to update it in archer-jankratochvil-expr.  Just there was some
conflict in dwarf2_build_psymtabs_hard due to
e56b9f4bab7f78c2749bc115cc2aa5bdd7375e8c which I resolved there wrong
regarding CU PC ranges determination.  IMO that
e56b9f4bab7f78c2749bc115cc2aa5bdd7375e8c should be reverted if possible.


Regards,
Jan

Re: [keiths-expr-cumulative] Regressions

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> And feel free to run the testsuite yourself and compare the
Jan> gdb.sum files from unpatched GDB.  :-)

If anybody is interested, you can easily use the auto-tester on the
compile farm to regtest two revisions.

Tom

Re: [keiths-expr-cumulative] Regressions

[Sami Wagiaalla]

Jan Kratochvil wrote:
> On Mon, 02 Mar 2009 16:39:17 +0100, Sami Wagiaalla wrote:
>>> Unfortunately even after this attached fix the branch is FAILing on:
>>> +FAIL: gdb.cp/namespace-using.exp: print _a
>>> +FAIL: gdb.cp/namespace-using.exp: print x
>> Are these the only regressions left ?
> 
> There is also that `constructor breakpoint' FAIL although assuming it is not
> from you.  And feel free to run the testsuite yourself and compare the gdb.sum
> files from unpatched GDB.  :-)

I do, before and after every patch and commit, but I could not reproduce 
these regressions. I normally test on f10 x8664, but I have tried on f10 
i386, and f11 i386, but not f11 i386 which I am about to do now. The 
only one I saw was:

	FAIL: gdb.cp/templates.exp: constructor breakpoint

Sami