headers
Joel Brobecker | 1 Feb 2010 09:19
Favicon

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

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
Permalink | Reply | 26 comments |
headers
Chris Sutcliffe | 1 Feb 2010 17:09
Picon

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

> 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
Permalink | Reply | 23 comments |
headers
Jan Kratochvil | 1 Feb 2010 21:20
Picon
Favicon

Re: [patch] Fix CLONE_VM vs. TLS [Re: Is CLONE_VM really needed in gdbserver?]

On Fri, 29 Jan 2010 13:41:28 +0100, Jan Kratochvil wrote:
> Going to check it in in some times as this change is IMO pre-approved.
[...]
> gdb/gdbserver/
> 2010-01-29  Jan Kratochvil  <jan.kratochvil <at> redhat.com>
> 
> 	PR libc/11214:
> 	* linux-low.c (linux_tracefork_child) [!(__UCLIBC__ && HAS_NOMMU)]: New.
> 	(linux_test_for_tracefork): Move `stack' into [__UCLIBC__ && HAS_NOMMU].
> 	(linux_test_for_tracefork) [!(__UCLIBC__ && HAS_NOMMU)]: New.
> 
> gdb/testsuite/
> 2010-01-29  Jan Kratochvil  <jan.kratochvil <at> redhat.com>
> 
> 	PR libc/11214:
> 	* gdb.threads/current-lwp-dead.c: Include features.h.
> 	(HAS_NOMMU): New.
> 	(fn, main): Move CLONE_VM into [__UCLIBC__ && HAS_NOMMU].

Checked-in:
	http://sourceware.org/ml/gdb-cvs/2010-02/msg00010.html

Regards,
Jan
Permalink | Reply | 0 comments |
headers
Michael Snyder | 1 Feb 2010 23:27
Favicon

Re: Installing python for gdb

Tom Tromey wrote:
>>>>>> "Michael" == Michael Snyder <msnyder <at> vmware.com> writes:
> 
> Michael> I'm on RHEL4 with python 2.3.something, which is not one of the
> Michael> version numbers that gdb / configure will accept.
> 
> In addition to what Daniel said, it may be possible to make gdb work
> with this version.  I don't know, but you could try it.

Well I don't know if RHEL4 is important any more --
it builds on RHEL5 but not on RHEL4.
Permalink | Reply | 1 comment |
headers
Joel Brobecker | 2 Feb 2010 05:16
Favicon

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

> 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
Permalink | Reply | 22 comments |
headers
Hui Zhu | 2 Feb 2010 06:59
Picon
Gravatar

Fwd: [patch] x86: ptrace and core-dump extensions for xstate

I am not sure.  Maybe we need do something around it after
linux-kernel support it.

Thanks,
Hui

---------- Forwarded message ----------
From: Suresh Siddha <suresh.b.siddha <at> intel.com>
Date: Tue, Feb 2, 2010 at 10:00
Subject: [patch] x86: ptrace and core-dump extensions for xstate
To: "H. Peter Anvin" <hpa <at> zytor.com>, Ingo Molnar <mingo <at> elte.hu>,
Thomas Gleixner <tglx <at> linutronix.de>, Roland McGrath
<roland <at> redhat.com>
Cc: LKML <linux-kernel <at> vger.kernel.org>, "Lu, Hongjiu"
<hongjiu.lu <at> intel.com>, "Lachner, Peter" <peter.lachner <at> intel.com>

Kernel ptrace, core dump extensions to support AVX state etc. This interface
(PTRACE_GETXSTATEREGS, PTRACE_SETXSTATEREGS, NT_X86_XSTATE) is designed to
support all the future state that gets supported using xsave/xrstor
infrastructure.

Looking at the memory layout saved by "xsave", one can't say which state
is represented in the memory layout. This is because if a particular state is
in init state, in the xsave hdr it can be represented by bit '0'. And hence
we can't really say by the xsave header wether a state is in init state or
the state is not saved in the memory layout.

And hence the xsave memory layout available through the PTRACE_GETXSTATEREGS
and the core dump(NT_X86_XSTATE) uses SW usable bytes [464..511] to convey
what state is represented in the memory layout.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Sutcliffe | 2 Feb 2010 13:35
Picon

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

> 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
Permalink | Reply | 21 comments |
headers
Kai Tietz | 2 Feb 2010 17:02

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

2010/2/2 Chris Sutcliffe <ir0nh34d <at> 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
(Continue reading)

Permalink | Reply | 18 comments |
headers
Christopher Faylor | 2 Feb 2010 17:27
Favicon

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

On Tue, Feb 02, 2010 at 05:02:11PM +0100, Kai Tietz wrote:
>2010/2/2 Chris Sutcliffe <ir0nh34d <at> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Sutcliffe | 2 Feb 2010 17:45
Picon

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

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
Permalink | Reply | 1 comment |

Gmane