[RFA] Fix an error in value_change_enclosing_type

[RFA] Fix an error in value_change_enclosing_type

[Pierre Muller]

the function value_change_enclosing_type
does not set the enlclosing_type field correctly if
the new_encl_type has a bigger length that the value type.

Its seems quite astonishing that this has not been noticed before, 
but I discovered it when trying to get 
the fpc-abi.c code to work correctly.

ChangeLog entry:

2002-10-07  Pierre Muller  <muller@ics.u-strasbg.fr>

        * values.c (value_change_enclosing_type): Set 
        enclosing_type field correctly also for the case where 
        more memory needs to be allocated.


$ cvs diff -u -p values.c
Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.41
diff -u -p -r1.41 values.c
--- values.c    18 Sep 2002 15:43:47 -0000      1.41
+++ values.c    7 Oct 2002 11:36:15 -0000
@@ -862,7 +862,9 @@ value_change_enclosing_type (struct valu
       struct value *prev;

       new_val = (struct value *) xrealloc (val, sizeof (struct value) + TYPE_LENGTH (new_encl_type));
-
+
+      VALUE_ENCLOSING_TYPE (new_val) = new_encl_type;
+
       /* We have to make sure this ends up in the same place in the value
         chain as the original copy, so it's clean-up behavior is the same.
         If the value has been released, this is a waste of time, but there


Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: [RFA] Fix an error in value_change_enclosing_type

[Elena Zannoni]

Pierre Muller writes:
 > 
 > 
 > 
 > the function value_change_enclosing_type
 > does not set the enlclosing_type field correctly if
 > the new_encl_type has a bigger length that the value type.
 > 
 > Its seems quite astonishing that this has not been noticed before, 
 > but I discovered it when trying to get 
 > the fpc-abi.c code to work correctly.
 > 

The fix seems OK. However, do you have a small testcase? It would be
good to add it to the testsuite.
Does this fix changes the results for the already existing tests?

thanks
Elena


 > ChangeLog entry:
 > 
 > 2002-10-07  Pierre Muller  <muller@ics.u-strasbg.fr>
 > 
 >         * values.c (value_change_enclosing_type): Set 
 >         enclosing_type field correctly also for the case where 
 >         more memory needs to be allocated.
 > 
 > 
 > $ cvs diff -u -p values.c
 > Index: values.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/values.c,v
 > retrieving revision 1.41
 > diff -u -p -r1.41 values.c
 > --- values.c    18 Sep 2002 15:43:47 -0000      1.41
 > +++ values.c    7 Oct 2002 11:36:15 -0000
 > @@ -862,7 +862,9 @@ value_change_enclosing_type (struct valu
 >        struct value *prev;
 > 
 >        new_val = (struct value *) xrealloc (val, sizeof (struct value) + TYPE_LENGTH (new_encl_type));
 > -
 > +
 > +      VALUE_ENCLOSING_TYPE (new_val) = new_encl_type;
 > +
 >        /* We have to make sure this ends up in the same place in the value
 >          chain as the original copy, so it's clean-up behavior is the same.
 >          If the value has been released, this is a waste of time, but there
 > 
 > 
 > Pierre Muller
 > Institut Charles Sadron
 > 6,rue Boussingault
 > F 67083 STRASBOURG CEDEX (France)
 > mailto:muller@ics.u-strasbg.fr
 > Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: [RFA] Fix an error in value_change_enclosing_type

[muller]

At 17:05 18/10/2002 -0400, Elena Zannoni wrote:
>Pierre Muller writes:
> > 
> > 
> > 
> > the function value_change_enclosing_type
> > does not set the enlclosing_type field correctly if
> > the new_encl_type has a bigger length that the value type.
> > 
> > Its seems quite astonishing that this has not been noticed before, 
> > but I discovered it when trying to get 
> > the fpc-abi.c code to work correctly.
> > 
>
>The fix seems OK. However, do you have a small testcase? It would be
>good to add it to the testsuite.
Sorry, but I don't have any, because I really don't even know
if this code is ever executed for C code. It is for
Free Pascal generated code, that is how I discovered that bug.
But I can't add tests with Free Pascal anyhow.

>Does this fix changes the results for the already existing tests?

Sorry, but I never worked with the testsuite,
so I can't answer this question.

Re: [RFA] Fix an error in value_change_enclosing_type

[Elena Zannoni]

muller@cerbere.u-strasbg.fr writes:
 > At 17:05 18/10/2002 -0400, Elena Zannoni wrote:
 > >Pierre Muller writes:
 > > > 
 > > > 
 > > > 
 > > > the function value_change_enclosing_type
 > > > does not set the enlclosing_type field correctly if
 > > > the new_encl_type has a bigger length that the value type.
 > > > 
 > > > Its seems quite astonishing that this has not been noticed before, 
 > > > but I discovered it when trying to get 
 > > > the fpc-abi.c code to work correctly.
 > > > 
 > >
 > >The fix seems OK. However, do you have a small testcase? It would be
 > >good to add it to the testsuite.
 > Sorry, but I don't have any, because I really don't even know
 > if this code is ever executed for C code. It is for
 > Free Pascal generated code, that is how I discovered that bug.
 > But I can't add tests with Free Pascal anyhow.
 > 

Oh, ok.

 > >Does this fix changes the results for the already existing tests?
 > 
 > Sorry, but I never worked with the testsuite,
 > so I can't answer this question.
 > 

Could you run make check in your gdb/testsuite directory in the build
tree?  All I meant is, whether or not the test results are different
before and after your change.

thanks
Elena

Re: [RFA] Fix an error in value_change_enclosing_type

[Pierre Muller]

A 22:39 22/10/2002, Elena Zannoni a écrit :
>muller@cerbere.u-strasbg.fr writes:
> > At 17:05 18/10/2002 -0400, Elena Zannoni wrote:
> > >Pierre Muller writes:
> > > > 
> > > > 
> > > > 
> > > > the function value_change_enclosing_type
> > > > does not set the enlclosing_type field correctly if
> > > > the new_encl_type has a bigger length that the value type.
> > > > 
> > > > Its seems quite astonishing that this has not been noticed before, 
> > > > but I discovered it when trying to get 
> > > > the fpc-abi.c code to work correctly.
> > > > 
> > >
> > >The fix seems OK. However, do you have a small testcase? It would be
> > >good to add it to the testsuite.
> > Sorry, but I don't have any, because I really don't even know
> > if this code is ever executed for C code. It is for
> > Free Pascal generated code, that is how I discovered that bug.
> > But I can't add tests with Free Pascal anyhow.
> > 
>
>Oh, ok.
>
> > >Does this fix changes the results for the already existing tests?
> > 
> > Sorry, but I never worked with the testsuite,
> > so I can't answer this question.
> > 
>
>Could you run make check in your gdb/testsuite directory in the build
>tree?  All I meant is, whether or not the test results are different
>before and after your change.
>
>thanks
>Elena


I tried to create a test program
using C++ code, but it does never seem to
use the code that I modified...

Thus, as I expected, the testsuite is unchanged:

Tested on a i386 linux  box:
(note that pthreads libs is not installed on that machine,
which creates several failures)
cvs tree from 29/10/2002:

                === gdb Summary ===

# of expected passes            8235
# of unexpected failures        52
# of unexpected successes       10
# of expected failures          168
# of unresolved testcases       3
# of untested testcases         9
# of unsupported tests          4
/home/pierre/gdb/build/origdb/testsuite/../../gdb/gdb version  2002-10-29-cvs -nx

same cvs tree + my patch :


                === gdb Summary ===

# of expected passes            8236
# of unexpected failures        51
# of unexpected successes       10
# of expected failures          168
# of unresolved testcases       3
# of untested testcases         9
# of unsupported tests          4
/home/pierre/gdb/build/origdb/testsuite/../../gdb/gdb version  2002-10-29-cvs -nx


But  the only difference is between gdbcvs.sum and modgdb.sum
is 
5166c5166
< FAIL: gdb.c++/annota2.exp: annotate-quit
---
> PASS: gdb.c++/annota2.exp: annotate-quit

which, when you look into gdb.c++/annota2.exp 
is said to be a tests that fails sometimes, but unreproducably.

So I think that we can consider that the 
testsuite result is unchanged.

Can I commit the patch?

Re: [RFA] Fix an error in value_change_enclosing_type

[Elena Zannoni]

Pierre Muller writes:
 > A 22:39 22/10/2002, Elena Zannoni a écrit :
 > >muller@cerbere.u-strasbg.fr writes:
 > > > At 17:05 18/10/2002 -0400, Elena Zannoni wrote:
 > > > >Pierre Muller writes:
 > > > > > 
 > > > > > 
 > > > > > 
 > > > > > the function value_change_enclosing_type
 > > > > > does not set the enlclosing_type field correctly if
 > > > > > the new_encl_type has a bigger length that the value type.
 > > > > > 
 > > > > > Its seems quite astonishing that this has not been noticed before, 
 > > > > > but I discovered it when trying to get 
 > > > > > the fpc-abi.c code to work correctly.
 > > > > > 
 > > > >
 > > > >The fix seems OK. However, do you have a small testcase? It would be
 > > > >good to add it to the testsuite.
 > > > Sorry, but I don't have any, because I really don't even know
 > > > if this code is ever executed for C code. It is for
 > > > Free Pascal generated code, that is how I discovered that bug.
 > > > But I can't add tests with Free Pascal anyhow.
 > > > 
 > >
 > >Oh, ok.
 > >
 > > > >Does this fix changes the results for the already existing tests?
 > > > 
 > > > Sorry, but I never worked with the testsuite,
 > > > so I can't answer this question.
 > > > 
 > >
 > >Could you run make check in your gdb/testsuite directory in the build
 > >tree?  All I meant is, whether or not the test results are different
 > >before and after your change.
 > >
 > >thanks
 > >Elena
 > 
 > 
 > I tried to create a test program
 > using C++ code, but it does never seem to
 > use the code that I modified...
 > 
 > Thus, as I expected, the testsuite is unchanged:
 > 
 > Tested on a i386 linux  box:
 > (note that pthreads libs is not installed on that machine,
 > which creates several failures)
 > cvs tree from 29/10/2002:
 > 

There is on more pass with your patch, looks like. Which test passed?
It could be a transient failure.

Otherwise, ok.

Elena


 >                 === gdb Summary ===
 > 
 > # of expected passes            8235
 > # of unexpected failures        52
 > # of unexpected successes       10
 > # of expected failures          168
 > # of unresolved testcases       3
 > # of untested testcases         9
 > # of unsupported tests          4
 > /home/pierre/gdb/build/origdb/testsuite/../../gdb/gdb version  2002-10-29-cvs -nx
 > 
 > same cvs tree + my patch :
 > 
 > 
 >                 === gdb Summary ===
 > 
 > # of expected passes            8236
 > # of unexpected failures        51
 > # of unexpected successes       10
 > # of expected failures          168
 > # of unresolved testcases       3
 > # of untested testcases         9
 > # of unsupported tests          4
 > /home/pierre/gdb/build/origdb/testsuite/../../gdb/gdb version  2002-10-29-cvs -nx
 > 
 > 
 > But  the only difference is between gdbcvs.sum and modgdb.sum
 > is 
 > 5166c5166
 > < FAIL: gdb.c++/annota2.exp: annotate-quit
 > ---
 > > PASS: gdb.c++/annota2.exp: annotate-quit
 > 
 > which, when you look into gdb.c++/annota2.exp 
 > is said to be a tests that fails sometimes, but unreproducably.
 > 
 > So I think that we can consider that the 
 > testsuite result is unchanged.
 > 
 > Can I commit the patch?

Re: [RFA] Fix an error in value_change_enclosing_type

[Pierre Muller]

At 01:05 04/11/2002, Elena Zannoni wrote:
>Pierre Muller writes:
> > A 22:39 22/10/2002, Elena Zannoni a écrit :
> > >muller@cerbere.u-strasbg.fr writes:
> > > > At 17:05 18/10/2002 -0400, Elena Zannoni wrote:
> > > > >Pierre Muller writes:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > the function value_change_enclosing_type
> > > > > > does not set the enlclosing_type field correctly if
> > > > > > the new_encl_type has a bigger length that the value type.
> > > > > > 
> > > > > > Its seems quite astonishing that this has not been noticed before, 
> > > > > > but I discovered it when trying to get 
> > > > > > the fpc-abi.c code to work correctly.
> > > > > > 
> > > > >
> > > > >The fix seems OK. However, do you have a small testcase? It would be
> > > > >good to add it to the testsuite.
> > > > Sorry, but I don't have any, because I really don't even know
> > > > if this code is ever executed for C code. It is for
> > > > Free Pascal generated code, that is how I discovered that bug.
> > > > But I can't add tests with Free Pascal anyhow.
> > > > 
> > >
> > >Oh, ok.
> > >
> > > > >Does this fix changes the results for the already existing tests?
> > > > 
> > > > Sorry, but I never worked with the testsuite,
> > > > so I can't answer this question.
> > > > 
> > >
> > >Could you run make check in your gdb/testsuite directory in the build
> > >tree?  All I meant is, whether or not the test results are different
> > >before and after your change.
> > >
> > >thanks
> > >Elena
> > 
> > 
> > I tried to create a test program
> > using C++ code, but it does never seem to
> > use the code that I modified...
> > 
> > Thus, as I expected, the testsuite is unchanged:
> > 
> > Tested on a i386 linux  box:
> > (note that pthreads libs is not installed on that machine,
> > which creates several failures)
> > cvs tree from 29/10/2002:
> > 
>
>There is on more pass with your patch, looks like. Which test passed?
>It could be a transient failure.

As explained below:
 > But  the only difference is between gdbcvs.sum and modgdb.sum
> > is 
> > 5166c5166
> > < FAIL: gdb.c++/annota2.exp: annotate-quit
> > ---
> > > PASS: gdb.c++/annota2.exp: annotate-quit
> > 
> > which, when you look into gdb.c++/annota2.exp 
> > is said to be a tests that fails sometimes, but unreproducably.
> > 
> > So I think that we can consider that the 
> > testsuite result is unchanged.


>Otherwise, ok.
>
>Elena

Thanks,
I commited the patch today, I just change the date in the ChangeLog...