Joel Brobecker | 1 Oct 01:54 2009

Re: [RFA/RFC] Fix watchpoint troubles on windows native.

> gdb ChangeLog:
> 2009-06-26  Pierre Muller  <muller <at> ics.u-strasbg.fr>
> 
> 	* windows-nat.c (cygwin_reset_dr): New forward declaration.
> 	(init_windows_ops): Set i386_dr_low.reset_addr field to 
> 	cygwin_reset_dr.
> 	(cygwin_reset_dr): New function

Has this patch been reviewed, yet? I can help with the testsuite part,
if it helps...

I wonder if this is going to work as is on Windows64...
--

-- 
Joel

Pedro Alves | 1 Oct 02:48 2009

Unbreak 'catch syscall' + multi-threading

As we were discussing yesterday, 'catch syscall' is unfortunately
broken with multi-threading in the mix, plus it has a few other
problems (present on 7.0 too, of course).  This patch fixes all the
issues I found.

 - "detach" when stopped at a syscall event dies horribly.  This was
   because we'd try to pass signal 0x85 to the inferior (SIGTRAP | 0x80, with
   0x80 being the magic sysgood/syscall bit).  We should never pass a
   ptrace SIGTRAP to the inferior.  get_pending_status was fixed to handle
   that., and I ended up simpl

 - In a multi-threaded app+all-stop: when gdb stops all threads to report
   an event, and some other thread hits a syscall trap, that event is left
   pending, but then a few issues trigger: the entry/return state of the
   syscall ends up inverted; if the user removes the syscall catchpoint
   before resuming, the pending event ends up reported as a spurious
   SIGTRAP or ??? signal (SIGTRAP | 0x80).  I've spend a good bit
   figuring out how/when syscall traps are reported, and what
   happens (at least on my kernel 2.6.24 x86_64) when we PTRACE_CONT
   to collect a pending SIGSTOP.  I've added hopefully compreensive
   (and correct!) explanations to the patch.  I wouldn't mind a double
   check.

 - Related to the previous point, even when not interested in a given
   syscall event, we'd still always stop all threads, report the event
   to the core, only to have the core immediately resume all threads
   again.  I've made it so that if we're ignoring the event, we
   resume the lwp hat reported the syscall immediately on the target
   side, bypassing the slow all-threads stop/resume.

(Continue reading)

Caz Yokoyama | 1 Oct 05:48 2009
Picon

RE: symbolic debug of loadable modules with kgdb light

Hello Joel and Eli,
Here is the patch which integrates your inputs. Even though I carefully look
through your inputs, there may be missing. Let me know if you find.

Notes:
- Use Ctrl-C, BREAK and SysRq-g according to Eli's suggestion.
- "make info" in gdb/doc has no complain.
- I always test the connection with Linux kernel.
- I did manual test like "help remote interrupt-sequence" and see its
output.
- I ran "make check". Let me know if you want its output.
-caz

-----Original Message-----
From: Joel Brobecker [mailto:brobecker <at> adacore.com] 
Sent: Wednesday, September 30, 2009 1:12 PM
To: Eli Zaretskii
Cc: Caz Yokoyama; pedro <at> codesourcery.com; gdb-patches <at> sourceware.org
Subject: Re: symbolic debug of loadable modules with kgdb light

> > + <at> item set interrupt-sequence
> > + <at> cindex interrupt remote programs
> > + <at> cindex select control-c, break or sysrq-g

BTW: It should be "set remote interrupt-sequence". Same for "show remote
interrupt-sequence".

--

-- 
Joel
(Continue reading)

Eli Zaretskii | 1 Oct 06:10 2009
Picon

Re: symbolic debug of loadable modules with kgdb light

> From: Caz Yokoyama <cazyokoyama <at> gmail.com>
> Cc: <pedro <at> codesourcery.com>,
> 	<gdb-patches <at> sourceware.org>
> Date: Wed, 30 Sep 2009 20:48:37 -0700
> 
> Hello Joel and Eli,
> Here is the patch which integrates your inputs. Even though I carefully look
> through your inputs, there may be missing. Let me know if you find.

Thanks.

> --- gdb/NEWS	15 Sep 2009 03:30:04 -0000	1.331
> +++ gdb/NEWS	1 Oct 2009 03:32:18 -0000
>  <at>  <at>  -3,6 +3,9  <at>  <at> 
>  
>  *** Changes since GDB 6.8
>  
> +* "set/show remotebreak" command is deprecated. Use "set/show remote
> +interrupt-sequence" instead.

I'd prefer this to be in the "New commands" section, even though it is
not strictly speaking a new command.

> +set remote interrupt-sequence [Ctrl-C | BREAK | SysRq-g]
> +show remote interrupt-sequence
> +  Allow the user to select one of ^C, a break or Magic SysRq g as the
> +  sequence to the remote target in order to interrupt the execution.
> +  Ctrl-C is a default.  Some system prefers BREAK which is high level of
> +  serial line for some certain time.  Linux kernel prefers SysRq-g, a.k.a
> +  Magic SysRq. It is BREAK signal and character 'g'.
(Continue reading)

Caz Yokoyama | 1 Oct 06:51 2009
Picon

RE: symbolic debug of loadable modules with kgdb light

How about this?
I am not familiar with texinfo.
-caz

-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org] 
Sent: Wednesday, September 30, 2009 9:11 PM
To: Caz Yokoyama
Cc: brobecker <at> adacore.com; pedro <at> codesourcery.com;
gdb-patches <at> sourceware.org
Subject: Re: symbolic debug of loadable modules with kgdb light

> From: Caz Yokoyama <cazyokoyama <at> gmail.com>
> Cc: <pedro <at> codesourcery.com>,
> 	<gdb-patches <at> sourceware.org>
> Date: Wed, 30 Sep 2009 20:48:37 -0700
> 
> Hello Joel and Eli,
> Here is the patch which integrates your inputs. Even though I carefully
look
> through your inputs, there may be missing. Let me know if you find.

Thanks.

> --- gdb/NEWS	15 Sep 2009 03:30:04 -0000	1.331
> +++ gdb/NEWS	1 Oct 2009 03:32:18 -0000
>  <at>  <at>  -3,6 +3,9  <at>  <at> 
>  
>  *** Changes since GDB 6.8
>  
(Continue reading)

Jonas Maebe | 1 Oct 11:17 2009
Picon

Re: [patch] Set calling convention of methods


Sorry for the delayed reply. I recently moved and don't have Internet  
access yet at home.

On 30 Sep 2009, at 18:25, Joel Brobecker wrote:

> Thanks for doing that, we really like testcases, so I appreciate
> the effort.

Since I always insist on tests for new functionality added to our  
compiler, it's only reasonable to hold my own patches to other  
projects to the same standard :)

> Overall, this looks OK to me, but Mark seemed interested in reviewing
> this patch, so please wait for his comments as well.

Ok. Note that my mail client is known to wrap text at 80 columns (and  
adds a space at the end of each wrapped line for detecting this  
operation). This behaviour cannot be disabled afaik, and yes, one  
could certainly consider this to be a bug. At the same time, it  
however also adds '"Format="flowed"; DelSp="yes"' to the Content-Type  
header, so mail clients on the other side can reconstruct the original  
text (if those clients support these modifiers, which I hope is the  
case).

In case this fails, too, I've also placed the new patch for download  
at http://users.elis.ugent.be/~jmaebe/gdb/gdb_borland_fastcall7.patch.txt

> Again, I think
> that dwarf2.h needs to be approved by binutils - it's probably going
(Continue reading)

Jonas Maebe | 1 Oct 11:21 2009
Picon

Re: [patch] Set calling convention of methods


On 30 Sep 2009, at 19:34, Tom Tromey wrote:

> Joel> Confirmed. It's written plain as day in the header.  The  
> sticky part
> Joel> is that Jonas does NOT have copyright assignment on file for  
> GCC, as
> Joel> far as I can tell...

That's correct, I only have them for binutils and gdb, afaik.

> I think this patch is small enough not to matter.

I hope so. I'll ask the FSF to also get a copyright assignment form  
for GCC (fortunately, that does not require an extra intervention from  
my employer).

Jonas

Doug Evans | 1 Oct 11:50 2009
Picon

Re: Unbreak 'catch syscall' + multi-threading

On Wed, Sep 30, 2009 at 5:48 PM, Pedro Alves <pedro <at> codesourcery.com> wrote:
> As we were discussing yesterday, 'catch syscall' is unfortunately
> broken with multi-threading in the mix, plus it has a few other
> problems (present on 7.0 too, of course).  This patch fixes all the
> issues I found.

Thanks.

> The code now uses (SIGTRAP | 0x80) directly in the couple
>   of places that need it, since that is exactly how the event is
>   described in the ptrace man page.

nit: 0x80 is still a magic  number no different than others (ISTM anyway).

IWBN to keep TRAP_IS_SYSCALL (change the name however you like &/|
only record 0x80 in it if you like).

Pedro Alves | 1 Oct 16:51 2009

Re: [PATCH/RFC] Signals & single-stepping

On Wednesday 30 September 2009 17:25:13, Daniel Jacobowitz wrote:
> Your patch doesn't reintroduce the problem from the PR, and the new
> tests in interrupt.exp pass on x86_64-linux.  I would really love
> someone else to volunteer to review it though - trap_expected confuses
> me horribly.  I'd guess this change could lead to hitting (and
> displaying) the breakpoint at the current PC a second time, which is
> undesirable.

Yes, this messes with hit counts, reruns user breakpoint
commands, etc.  Even some internal breakpoints don't like to
be re-hit for no reason.  E.g., see linux-thread-db.c:check_event
"Cannot get thread event message".

I think the issue is that when stepping over a breakpoint,
for simplicity, GDB always removes all breakpoints.  What if
we made it remove only breakpoints at stop_pc?

--

-- 
Pedro Alves

Pierre Muller | 1 Oct 17:21 2009
Picon
Picon

[RFA] fix some problems in testsuite

  While trying to test the release candidate
on a ubuntu server i386-pc-linux
a got several UNTESTED related to warnings
issued by gcc.
  It seems that the installed version of gcc 
does generate warnings for format by default.

See
http://sourceware.org/ml/gdb/2009-10/msg00014.html

This patch handles 1),2) and 6)
problems in that email.

Tested on compile farm gcc16,
no changes there... (that gcc seems less picky).

Is this OK?

Pierre Muller
Pascal language support maintainer for GDB

gdb/testsuite ChangeLog entry:

2009-10-01  Pierre Muller  <muller <at> ics.u-strasbg.fr>

	* gdb.base/fileio.c (test_lseek): typecast off_t ret variable to
	long type.
	(test_unlink): Correct printf string.
	* gdb.base/checkpoint.c (main): Correct fprintf string for variable
i.
(Continue reading)


Gmane