[gdb-7.1] 10 days to branching...

[gdb-7.1] 10 days to branching...

[Joel Brobecker]

Hello,

We're getting close to planned branching time, so I was wondering how
we were doing.  Looking at the wiki page for the release, I see:

  * [Jan] PIE support extension for biarch (64->32) mode.

  * [Stan] Tracepoint support (host).

  * [Pedro] Tracepoint support (target).

  * [Pedro, Vladimir] Add non-stop documentation user/internal/MI
    [...]

Is any of the above done? If there are some items still not done,
do we think that it'll be done by then? Lastly, are there new issues
that came up since the last update?

Thanks,
-- 
Joel

Re: [gdb-7.1] 10 days to branching...

[Chris Sutcliffe]

> Lastly, are there new issues that came up since the last update?

As I mentioned in this email:

http://sourceware.org/ml/gdb/2010-01/msg00189.html

I've noticed an issue with MinGW hosted GDB using the current CVS head
(I tested with a 20100130 snapshot as well) compared to the behaviour
I see with 7.0.1.  Is this expected?

Thank you,

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org

Re: [gdb-7.1] 10 days to branching...

[Joel Brobecker]

> I've noticed an issue with MinGW hosted GDB using the current CVS head
> (I tested with a 20100130 snapshot as well) compared to the behaviour
> I see with 7.0.1.  Is this expected?

I don't know - I had never heard of anyone doing this kind of build
before:  From what I can tell, you are building a MinGW debugger using
a cygwin compiler.  If no one answered, it's probably because no one
has anything to say (including: "that ought to work").  Have you tried
using a MinGW compiler instead?

-- 
Joel

Re: [gdb-7.1] 10 days to branching...

[Chris Sutcliffe]

> I don't know - I had never heard of anyone doing this kind of build
> before:  From what I can tell, you are building a MinGW debugger using
> a cygwin compiler.  If no one answered, it's probably because no one
> has anything to say (including: "that ought to work").  Have you tried
> using a MinGW compiler instead?

For the mingw-w64 build, I did indeed build from within Cygwin using
the mingw-w64 cross compiling toolchain provided by the mingw-w64
project.  For the MinGW32 binary I built it using MSYS and the MinGW
compiler.  In both cases this is the method I used to the build the
7.0.1 binary.

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org

Re: [gdb-7.1] 10 days to branching...

[Kai Tietz]

2010/2/2 Chris Sutcliffe <ir0nh34d@gmail.com>:
>> I don't know - I had never heard of anyone doing this kind of build
>> before:  From what I can tell, you are building a MinGW debugger using
>> a cygwin compiler.  If no one answered, it's probably because no one
>> has anything to say (including: "that ought to work").  Have you tried
>> using a MinGW compiler instead?
>
> For the mingw-w64 build, I did indeed build from within Cygwin using
> the mingw-w64 cross compiling toolchain provided by the mingw-w64
> project.  For the MinGW32 binary I built it using MSYS and the MinGW
> compiler.  In both cases this is the method I used to the build the
> 7.0.1 binary.

Yes, I can confirm that buiding on a cygwin host by a valid
cross-compiler is working nicely. I justed tried, and for me it still
works. Possibly an issue about passed configure options?

Just one point I found today. The new break-point handling seems to
have problems in certain ways for me (at least on win32 versions). I
get in case of setting breakpoints in Obj-C always the assertation
'set_raw_breakpoint: Assertation sal.pspace != NULL' failed'. This is
new and is somehow related to recent enhancements to breakpoint
handling.

Regards,
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [gdb-7.1] 10 days to branching...

[Christopher Faylor]

On Tue, Feb 02, 2010 at 05:02:11PM +0100, Kai Tietz wrote:
>2010/2/2 Chris Sutcliffe <ir0nh34d@gmail.com>:
>>> I don't know - I had never heard of anyone doing this kind of build
>>> before: ?From what I can tell, you are building a MinGW debugger using
>>> a cygwin compiler. ?If no one answered, it's probably because no one
>>> has anything to say (including: "that ought to work"). ?Have you tried
>>> using a MinGW compiler instead?
>>
>> For the mingw-w64 build, I did indeed build from within Cygwin using
>> the mingw-w64 cross compiling toolchain provided by the mingw-w64
>> project. ?For the MinGW32 binary I built it using MSYS and the MinGW
>> compiler. ?In both cases this is the method I used to the build the
>> 7.0.1 binary.
>
>Yes, I can confirm that buiding on a cygwin host by a valid
>cross-compiler is working nicely. I justed tried, and for me it still
>works. Possibly an issue about passed configure options?
>
>Just one point I found today. The new break-point handling seems to
>have problems in certain ways for me (at least on win32 versions). I
>get in case of setting breakpoints in Obj-C always the assertation
>'set_raw_breakpoint: Assertation sal.pspace != NULL' failed'. This is
>new and is somehow related to recent enhancements to breakpoint
>handling.

I haven't noticed this but I haven't rebuilt my version of gdb in a
couple of months.  I'll take a look tonight when I get home.  Or, maybe
someone can provide some (excuse the expression) insight before then.

cgf

Re: [gdb-7.1] 10 days to branching...

[Chris Sutcliffe]

Hi Kai,

>> For the mingw-w64 build, I did indeed build from within Cygwin using
>> the mingw-w64 cross compiling toolchain provided by the mingw-w64
>> project.  For the MinGW32 binary I built it using MSYS and the MinGW
>> compiler.  In both cases this is the method I used to the build the
>> 7.0.1 binary.
>
> Yes, I can confirm that buiding on a cygwin host by a valid
> cross-compiler is working nicely. I justed tried, and for me it still
> works. Possibly an issue about passed configure options?

Can you please provide the configure options you used?

Thank you,

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org

Re: [gdb-7.1] 10 days to branching...

[Kai Tietz]

2010/2/2 Chris Sutcliffe <ir0nh34d@gmail.com>:
> Hi Kai,
>
>>> For the mingw-w64 build, I did indeed build from within Cygwin using
>>> the mingw-w64 cross compiling toolchain provided by the mingw-w64
>>> project.  For the MinGW32 binary I built it using MSYS and the MinGW
>>> compiler.  In both cases this is the method I used to the build the
>>> 7.0.1 binary.
>>
>> Yes, I can confirm that buiding on a cygwin host by a valid
>> cross-compiler is working nicely. I justed tried, and for me it still
>> works. Possibly an issue about passed configure options?
>
> Can you please provide the configure options you used?
>
> Thank you,
>
> Chris
>
> --
> Chris Sutcliffe
> http://emergedesktop.org
>
Well, I use for x86 --host=i686-w64-mingw32 --target=i686-w64-mingw32.
gtk I disable in general, too.

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [gdb-7.1] 10 days to branching...

[Christopher Faylor]

On Tue, Feb 02, 2010 at 05:02:11PM +0100, Kai Tietz wrote:
>2010/2/2 Chris Sutcliffe <ir0nh34d@gmail.com>:
>>> I don't know - I had never heard of anyone doing this kind of build
>>> before: ?From what I can tell, you are building a MinGW debugger using
>>> a cygwin compiler. ?If no one answered, it's probably because no one
>>> has anything to say (including: "that ought to work"). ?Have you tried
>>> using a MinGW compiler instead?
>>
>> For the mingw-w64 build, I did indeed build from within Cygwin using
>> the mingw-w64 cross compiling toolchain provided by the mingw-w64
>> project. ?For the MinGW32 binary I built it using MSYS and the MinGW
>> compiler. ?In both cases this is the method I used to the build the
>> 7.0.1 binary.
>
>Yes, I can confirm that buiding on a cygwin host by a valid
>cross-compiler is working nicely. I justed tried, and for me it still
>works. Possibly an issue about passed configure options?
>
>Just one point I found today. The new break-point handling seems to
>have problems in certain ways for me (at least on win32 versions). I
>get in case of setting breakpoints in Obj-C always the assertation
>'set_raw_breakpoint: Assertation sal.pspace != NULL' failed'. This is
>new and is somehow related to recent enhancements to breakpoint
>handling.

I don't see anything like this when setting breakpoints in a c++
app.  I'm not familiar with objective-C but I believe I managed to
build a simple hello world app.  I set a breakpoint in main with
no problem.

This is with a i686-cygwin gdb built on linux.

cgf

Re: [gdb-7.1] 10 days to branching...

[Kai Tietz]

2010/2/2 Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>:
> On Tue, Feb 02, 2010 at 05:02:11PM +0100, Kai Tietz wrote:
>>2010/2/2 Chris Sutcliffe <ir0nh34d@gmail.com>:
>>>> I don't know - I had never heard of anyone doing this kind of build
>>>> before: ?From what I can tell, you are building a MinGW debugger using
>>>> a cygwin compiler. ?If no one answered, it's probably because no one
>>>> has anything to say (including: "that ought to work"). ?Have you tried
>>>> using a MinGW compiler instead?
>>>
>>> For the mingw-w64 build, I did indeed build from within Cygwin using
>>> the mingw-w64 cross compiling toolchain provided by the mingw-w64
>>> project. ?For the MinGW32 binary I built it using MSYS and the MinGW
>>> compiler. ?In both cases this is the method I used to the build the
>>> 7.0.1 binary.
>>
>>Yes, I can confirm that buiding on a cygwin host by a valid
>>cross-compiler is working nicely. I justed tried, and for me it still
>>works. Possibly an issue about passed configure options?
>>
>>Just one point I found today. The new break-point handling seems to
>>have problems in certain ways for me (at least on win32 versions). I
>>get in case of setting breakpoints in Obj-C always the assertation
>>'set_raw_breakpoint: Assertation sal.pspace != NULL' failed'. This is
>>new and is somehow related to recent enhancements to breakpoint
>>handling.
>
> I don't see anything like this when setting breakpoints in a c++
> app.  I'm not familiar with objective-C but I believe I managed to
> build a simple hello world app.  I set a breakpoint in main with
> no problem.
>
> This is with a i686-cygwin gdb built on linux.
>
> cgf
>

Hallo Christopher,

well for basic Object-C apps, I don't see the issue, too. For C and
C++ I couldn't reproduce this. This seems to happen on setting of
breakpoint on Object-C methods in shared object.
I tried two different ways to set breakpoint. First variant is before
starting (as pending breakpoint). This works a long as the DLL isn't
loaded. As soon as it is, the gdb gives the above mentioned
asseration. Second variant is, starting application and stopping it by
Crtl-C, setting breakpoint. Here the problem is shown directly.
I can provide the application I have (it is an about 50MB binary) and
owned by the company I am working, but it seems that in such scenario
the pspace remains NULL.

Thanks for you trying,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [gdb-7.1] 10 days to branching...

[Christopher Faylor]

On Wed, Feb 03, 2010 at 09:19:57AM +0100, Kai Tietz wrote:
>2010/2/2 Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>:
>> On Tue, Feb 02, 2010 at 05:02:11PM +0100, Kai Tietz wrote:
>>>2010/2/2 Chris Sutcliffe <ir0nh34d@gmail.com>:
>>>>> I don't know - I had never heard of anyone doing this kind of build
>>>>> before: ?From what I can tell, you are building a MinGW debugger using
>>>>> a cygwin compiler. ?If no one answered, it's probably because no one
>>>>> has anything to say (including: "that ought to work"). ?Have you tried
>>>>> using a MinGW compiler instead?
>>>>
>>>> For the mingw-w64 build, I did indeed build from within Cygwin using
>>>> the mingw-w64 cross compiling toolchain provided by the mingw-w64
>>>> project. ?For the MinGW32 binary I built it using MSYS and the MinGW
>>>> compiler. ?In both cases this is the method I used to the build the
>>>> 7.0.1 binary.
>>>
>>>Yes, I can confirm that buiding on a cygwin host by a valid
>>>cross-compiler is working nicely. I justed tried, and for me it still
>>>works. Possibly an issue about passed configure options?
>>>
>>>Just one point I found today. The new break-point handling seems to
>>>have problems in certain ways for me (at least on win32 versions). I
>>>get in case of setting breakpoints in Obj-C always the assertation
>>>'set_raw_breakpoint: Assertation sal.pspace != NULL' failed'. This is
>>>new and is somehow related to recent enhancements to breakpoint
>>>handling.
>>
>> I don't see anything like this when setting breakpoints in a c++
>> app. ?I'm not familiar with objective-C but I believe I managed to
>> build a simple hello world app. ?I set a breakpoint in main with
>> no problem.
>>
>> This is with a i686-cygwin gdb built on linux.
>>
>> cgf
>>
>
>Hallo Christopher,
>
>well for basic Object-C apps, I don't see the issue, too. For C and
>C++ I couldn't reproduce this. This seems to happen on setting of
>breakpoint on Object-C methods in shared object.
>I tried two different ways to set breakpoint. First variant is before
>starting (as pending breakpoint). This works a long as the DLL isn't
>loaded. As soon as it is, the gdb gives the above mentioned
>asseration. Second variant is, starting application and stopping it by
>Crtl-C, setting breakpoint. Here the problem is shown directly.
>I can provide the application I have (it is an about 50MB binary) and
>owned by the company I am working, but it seems that in such scenario
>the pspace remains NULL.

Any possibility that you can confirm whether this is a windows-only
problem?

I think the only way to do that is to provide a test case.

cgf

Re: [gdb-7.1] 10 days to branching...

[Tom Tromey]

>>>>> "cgf" == Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org> writes:

cgf> Any possibility that you can confirm whether this is a windows-only
cgf> problem?

cgf> I think the only way to do that is to provide a test case.

It is not Windows-specific.  I reproduced it with a c++ program on my
x86 F11 box.

The program comes from PR 9032:

    #include <stdio.h>
    class InstSelection {
    public:
      InstSelection(double d) {
      }
    public:
      virtual ~InstSelection(void);
      void dump(void);
    };

    InstSelection::~InstSelection(void)
    {
    }

    void InstSelection::dump(void)
    {
      printf("InstSelection::dump here\n");
    }

    int main(void)
    {
      InstSelection *is = new InstSelection(17.0);
      is->dump();
      delete is; is = 0;
      return 0;
    }

I compiled it with the system g++, then ran CVS head gdb on the
executable.  Finally:

(gdb) b InstSelection::InstSelection
../../src/gdb/breakpoint.c:4962: internal-error: set_raw_breakpoint: Assertion `sal.pspace != NULL' failed.


The sal causing the problem in set_raw_breakpoint:

(top-gdb) p sal
$10 = {
  pspace = 0x0, 
  symtab = 0x0, 
  section = 0x0, 
  line = 0, 
  pc = 0, 
  end = 0, 
  explicit_pc = 0, 
  explicit_line = 0
}

That seems odd.

Tom

Re: [gdb-7.1] 10 days to branching...

[Joel Brobecker]

> (gdb) b InstSelection::InstSelection
> ../../src/gdb/breakpoint.c:4962: internal-error: set_raw_breakpoint: Assertion `sal.pspace != NULL' failed.

ISTR that I saw something similar with Ada - the problem was in
uncontributed code (mostly support for homonyms throught the
introduction of a canonical location) which therefore did not get
updated during the introduction of the sal.pspace.

Basically, everywhere we created a sal, we first initialized it
(init_sal), and then filled the different fields. We just forgot
to fill in the pspace.  This is from memory since, stupid me,
I did one commit in AdaCore's tree containing both the resync
with the FSF tree, and the associated necessary adjustments. Grrr...

The fact that you reproduced the problem with C++ does not necessarily
indicate that you reproduced the same problem, although I hope you did.

Hope this helps...

-- 
Joel

Re: [gdb-7.1] 10 days to branching...

[Pedro Alves]

On Friday 05 February 2010 22:02:22, Tom Tromey wrote:
> >>>>> "cgf" == Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org> writes:
> 
> cgf> Any possibility that you can confirm whether this is a windows-only
> cgf> problem?
> 
> cgf> I think the only way to do that is to provide a test case.
> 
> It is not Windows-specific.  I reproduced it with a c++ program on my
> x86 F11 box.
> 
> The program comes from PR 9032:
> 
>     #include <stdio.h>
>     class InstSelection {
>     public:
>       InstSelection(double d) {
>       }
>     public:
>       virtual ~InstSelection(void);
>       void dump(void);
>     };
> 
>     InstSelection::~InstSelection(void)
>     {
>     }
> 
>     void InstSelection::dump(void)
>     {
>       printf("InstSelection::dump here\n");
>     }
> 
>     int main(void)
>     {
>       InstSelection *is = new InstSelection(17.0);
>       is->dump();
>       delete is; is = 0;
>       return 0;
>     }
> 
> I compiled it with the system g++, then ran CVS head gdb on the
> executable.  Finally:
> 
> (gdb) b InstSelection::InstSelection
> ../../src/gdb/breakpoint.c:4962: internal-error: set_raw_breakpoint: Assertion `sal.pspace != NULL' failed.
> 
> 
> The sal causing the problem in set_raw_breakpoint:
> 
> (top-gdb) p sal
> $10 = {
>   pspace = 0x0, 
>   symtab = 0x0, 
>   section = 0x0, 
>   line = 0, 
>   pc = 0, 
>   end = 0, 
>   explicit_pc = 0, 
>   explicit_line = 0
> }
> 
> That seems odd.

This one's been described and diagnosed in
PR10966 <http://sourceware.org/bugzilla/show_bug.cgi?id=10966>

The expr-cumulative work fixes this, but I listed in the PR
two possible quick workarounds.

Has a small objc testcase been found yet?  It could
simply be something forgetting to set the sal's pspace
around decode_objc, but then I'm confused at how it only
triggers in some cases, and the objc tests in our
testsuite pass.  It could yet be another bug that
was masked out before the pspace assertion was added,
like the PR10966 bug.

-- 
Pedro Alves

Re: [gdb-7.1] 10 days to branching...

[Matt Rice]

>>  Kai Tietz <ktietz70@googlemail.com> wrote:
>> This seems to happen on setting of
>> breakpoint on Object-C methods in shared object.
>
>On Sat, Feb 6, 2010 at 8:26 AM, Pedro Alves <pedro@codesourcery.com> wrote:
>
> This one's been described and diagnosed in
> PR10966 <http://sourceware.org/bugzilla/show_bug.cgi?id=10966>
>
> The expr-cumulative work fixes this, but I listed in the PR
> two possible quick workarounds.
>
> Has a small objc testcase been found yet?  It could
> simply be something forgetting to set the sal's pspace
> around decode_objc, but then I'm confused at how it only
> triggers in some cases, and the objc tests in our
> testsuite pass.  It could yet be another bug that
> was masked out before the pspace assertion was added,
> like the PR10966 bug.

Sorry I can't really look into this atm, but if Kai is right, the
tests I sent in the below link may reproduce as they set breakpoints
on objc methods in shared libraries, maybe with some coercing to avoid
the ambiguity problems e.g. using a unique method name

I still need to update it to reflect Joel's comments later in the thread though
will get back to this when I can budget in some new hardware.

http://sourceware.org/ml/gdb-patches/2009-09/msg00746.html

Re: [gdb-7.1] 10 days to branching...

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

[ gdb crasher ]

Pedro> This one's been described and diagnosed in
Pedro> PR10966 <http://sourceware.org/bugzilla/show_bug.cgi?id=10966>

Pedro> The expr-cumulative work fixes this, but I listed in the PR
Pedro> two possible quick workarounds.

It may go without saying, but I think we should apply one of the
workarounds to the 7.1 branch, once it is made.

I'll add a note to the 7.1 wiki page.

Tom

Re: [gdb-7.1] 10 days to branching...

[Joel Brobecker]

> |       sym_arr[i1] = lookup_symbol_in_language (phys_name,
> |                                    NULL, FUNCTIONS_DOMAIN,
> |                                    language,
> |                                    (int *) NULL);
> | -      if (sym_arr[i1])
> | +      /* See PR10966.  Remove check on symbol domain and class when
> | +         we stop using (bad) linkage names on constructors.  */
> | +      if (sym_arr[i1] && (SYMBOL_DOMAIN (sym_arr[i1]) == VAR_DOMAIN
> | +                          && SYMBOL_CLASS (sym_arr[i1]) == LOC_BLOCK))
> |         i1++;

Tested with no regression on my end. Regarding my C++ compiler quality,
I looked at gdb.sum, and I have 32 KFAILs and 20 FAILs in gdb.cp.
However, upon further testing, it appears that the patches does not
have the desired effect (or I applied it at the wrong location?):

    (gdb) b Foo::Foo
    the class Foo does not have any method named Foo
    Hint: try 'Foo::Foo<TAB> or 'Foo::Foo<ESC-?>
    (Note leading single quote.)
    Make breakpoint pending on future shared library load? (y or [n]) n

-- 
Joel

Re: [gdb-7.1] 10 days to branching...

[Pedro Alves]

Thanks for taking care of this.

On Friday 12 February 2010 06:15:58, Joel Brobecker wrote:
> > |       sym_arr[i1] = lookup_symbol_in_language (phys_name,
> > |                                    NULL, FUNCTIONS_DOMAIN,
> > |                                    language,
> > |                                    (int *) NULL);
> > | -      if (sym_arr[i1])
> > | +      /* See PR10966.  Remove check on symbol domain and class when
> > | +         we stop using (bad) linkage names on constructors.  */
> > | +      if (sym_arr[i1] && (SYMBOL_DOMAIN (sym_arr[i1]) == VAR_DOMAIN
> > | +                          && SYMBOL_CLASS (sym_arr[i1]) == LOC_BLOCK))
> > |         i1++;
> 
> Tested with no regression on my end. Regarding my C++ compiler quality,
> I looked at gdb.sum, and I have 32 KFAILs and 20 FAILs in gdb.cp.
> However, upon further testing, it appears that the patches does not
> have the desired effect (or I applied it at the wrong location?):
> 
>     (gdb) b Foo::Foo
>     the class Foo does not have any method named Foo
>     Hint: try 'Foo::Foo<TAB> or 'Foo::Foo<ESC-?>
>     (Note leading single quote.)
>     Make breakpoint pending on future shared library load? (y or [n]) n
> 

This is what I'd expect.  In previous GDBs, if there's only one
contructor, like, say:

struct Foo
{
	Foo()
	{}
};

Foo foo;

int main (int argc, char **argv)
{
	return 0;
}

GDB would just do nothing in response to that command.

(gdb) b Foo::Foo
(gdb)

If you had multiple constructors, say:

struct Foo
{
	Foo()
	{}
	Foo(const char *foo)
	{}
};

Foo foo;
Foo bar("bar");

int main (int argc, char **argv)
{
	return 0;
}

GDB would create broken breakpoints for them at address 0...

(gdb) b Foo::Foo
[0] cancel
[1] all
?HERE
?HERE
>

"?HERE" was never supposed to be visible to the user, and should
have been replaced by the proper name for the
function (the constructors), but since GDB found the wrong symbol...

> 1
Breakpoint 2 at 0x0
Breakpoint 3 at 0x0
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
2       breakpoint     keep y   0x0000000000000000
3       breakpoint     keep y   0x0000000000000000

Not very useful either.

That happens is that the wrong symbols are found, and a
broken sal escapes to the breakpoints module.  Nowadays,
there's an assertion that catches this (without the
assertion, we'd crash instead).


Note that even with the workaround, this still works:

 (gdb) b 'Foo::Foo()'
 Breakpoint 2 at 0x8048455: file foo.cc, line 3.
 (gdb) b 'Foo::Foo(const char *)'
 Breakpoint 3 at 0x804845b: file foo.cc, line 5.

It's the Foo::Foo form that's been broken for ages:

 (gdb) p Foo::Foo
 Cannot look up value of a typedef


I just tried GDB 5.3 and 6.0, and they seem to get it
right though, so this was a regression at some point.  :-)

-- 
Pedro Alves

Re: [gdb-7.1] 10 days to branching...

[Pedro Alves]

On Friday 12 February 2010 05:10:07, Joel Brobecker wrote:
> The following diff is the workaround that sounds the simplest.
> I will test it on my end, but I'm not certain of the quality of my C++
> compiler (I remember getting more FAILs than I think I should). Anyone
> wants to test it?  I want to apply the workaround immediately after
> I created the branch so that I can create the first pre-release right
> after.

How far are we from getting the expr-cumulative branch
merged?  If it's not getting in soon after branching, then
I'd suggest applying the workaround before branching, so that
we don't fix a crash in 7.1 and leave it regressing in mainline.
We can always revert the workaround when or before the
expr-cumulative stuff goes in.

-- 
Pedro Alves

Re: [gdb-7.1] 10 days to branching...

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> How far are we from getting the expr-cumulative branch
Pedro> merged?

The biggest series is approved for post-7.1.
I assume it will go in shortly after the branch is made.

There are various other things on expr-cumulative that haven't been
cleaned up for submission yet.  Those will happen once the first big
("physname") series goes in.

Tom

Re: [gdb-7.1] 10 days to branching...

[Pedro Alves]

On Friday 12 February 2010 17:12:33, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> 
> Pedro> How far are we from getting the expr-cumulative branch
> Pedro> merged?
> 
> The biggest series is approved for post-7.1.
> I assume it will go in shortly after the branch is made.

Great, thanks.  It's fine for the workaround to be applied only on
the branch then.

> There are various other things on expr-cumulative that haven't been
> cleaned up for submission yet.  Those will happen once the first big
> ("physname") series goes in.

-- 
Pedro Alves

Re: [gdb-7.1] 10 days to branching...

[Michael Snyder]

Pedro Alves wrote:
> On Friday 12 February 2010 17:12:33, Tom Tromey wrote:
>>>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
>> Pedro> How far are we from getting the expr-cumulative branch
>> Pedro> merged?
>>
>> The biggest series is approved for post-7.1.
>> I assume it will go in shortly after the branch is made.
> 
> Great, thanks.  It's fine for the workaround to be applied only on
> the branch then.
> 
>> There are various other things on expr-cumulative that haven't been
>> cleaned up for submission yet.  Those will happen once the first big
>> ("physname") series goes in.
> 

Let's get the MI-reverse patch into 7.1.  I don't care whether we
do it before or after the branch, but this change has been sitting
in the queue for a long time.

AFAIK, the last patches were those dated in the neighborhood
of 12/22/09?

Re: [gdb-7.1] 10 days to branching...

[André Pönitz]

On Tuesday 02 February 2010 13:35:27 Chris Sutcliffe wrote:
> [...] For the mingw-w64 build, I did indeed build from within Cygwin using
> the mingw-w64 cross compiling toolchain provided by the mingw-w64
> project.  For the MinGW32 binary I built it using MSYS and the MinGW
> compiler.  In both cases this is the method I used to the build the
> 7.0.1 binary.

Is this configured for using Python scripting?

Andre'

Re: [gdb-7.1] 10 days to branching...

[Chris Sutcliffe]

>> [...] For the mingw-w64 build, I did indeed build from within Cygwin using
>> the mingw-w64 cross compiling toolchain provided by the mingw-w64
>> project.  For the MinGW32 binary I built it using MSYS and the MinGW
>> compiler.  In both cases this is the method I used to the build the
>> 7.0.1 binary.
>
> Is this configured for using Python scripting?

No, I've only statically linked to libexpat.  I've rebuilt using the
20100202 snapshot and changed my configuration options a little and
the snapshot seems to be behaving like 7.0.1 now, with the added bonus
of so far not seeing the symtab / psymtab warnings.

Thank you all for your time.

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org

Re: [gdb-7.1] 10 days to branching...

[Stan Shebs]

Joel Brobecker wrote:
>   * [Stan] Tracepoint support (host).
>
>   * [Pedro] Tracepoint support (target).
>   
We've both gotten sucked into firefighting, so there's not going to be 
much more tracepointwise for 7.1, alas.  So don't hold off branching on 
our account.

Stan

Re: [gdb-7.1] 10 days to branching...

[Joel Brobecker]

> We've both gotten sucked into firefighting, so there's not going to
> be much more tracepointwise for 7.1, alas.  So don't hold off
> branching on our account.

Thanks for letting me know.

-- 
Joel