Abhijit Halder | 1 Aug 2011 11:49
Picon

Query: About process

Hi,

I am pretty new in this community. Just curious to know whether I will
get any notification if my patch get accepted or rejected.

Thanks,
Abhijit Halder

Phil Muldoon | 1 Aug 2011 11:50
Picon
Favicon

Re: [patch] python prompt additions at first prompt.

Matt Rice <ratmice <at> gmail.com> writes:

> little bug with the new python prompt stuff, the prompt_hook doesn't
> take effect until the second prompt.

Thanks for doing this.  This looks fine to me, apart from one question.

For tests, there are prompt tests in the python.exp file for prompt
substitutions.  For passing arguments to GDB at start-up, see usage of
$GDBFLAGS in the testsuite.

> -     prompt, otherwise just print the prompt.  */
> -  if (async_command_editing_p)
> -    {
> -      int length;
> -      char *a_prompt;
> -      char *gdb_prompt = get_prompt (0);
> -
> -      /* Tell readline what the prompt to display is and what function
> -         it will need to call after a whole line is read.  This also
> -         displays the first prompt.  */
> -      length = strlen (get_prefix (0))
> -	+ strlen (gdb_prompt) + strlen (get_suffix(0)) + 1;
> -      a_prompt = (char *) alloca (length);
> -      strcpy (a_prompt, get_prefix (0));
> -      strcat (a_prompt, gdb_prompt);
> -      strcat (a_prompt, get_suffix (0));
> -      rl_callback_handler_install (a_prompt, input_handler);
> -    }
> -  else
(Continue reading)

Phil Muldoon | 1 Aug 2011 11:57
Picon
Favicon

Re: Patches for building GDB with MinGW

Eli Zaretskii <eliz <at> gnu.org> writes:

> The second part, about Python initializations, was discussed
> in this thread:
>
>   http://sourceware.org/ml/gdb/2011-07/msg00107.html

Thanks for doing this.  It looks fine to me.  With the patch, all the
(Python) tests pass ok on Linux based builds too?

It's corner-cases like this that sometimes make me think we should
revive the gdb-internal manual.  Purely because on hosts that
contributors do not have access too, will, without diligence continue to
fail/bit-rot.  Anyway, that is another discussion, probably for another
time. ;)

> Okay to commit?

It looks fine to me, but I am not a maintainer.

Cheers

Phil

Phil Muldoon | 1 Aug 2011 12:05
Picon
Favicon

Re: Query: About process

Abhijit Halder <abhijit.k.halder <at> gmail.com> writes:

> Hi,
>
> I am pretty new in this community. Just curious to know whether I will
> get any notification if my patch get accepted or rejected.

Your patch will get reviewed (by anybody, but normally by a
maintainer).  They may require changes to the patch.   

Only a maintainer can grant you approval to commit your patch.  The
CONTRIBUTE file in the gdb/ source directory gives a good overview.

Sometimes, patches can be missed.  I generally "ping" patches after a
week if no review has been forthcoming.  Sometimes the maintainer
work-load is very high, so some things get missed/forgotten.  It is
perfectly acceptable to "ping" a patch after a reasonable time, and you
will not be breaking any etiquette by doing so.

Finally, questions like this generally go to gdb <at> sourceware.org, and
patch discussion about actual patches to gdb-patches <at> sourceware.org.
These rules are very loosely applied, so you have done nothing wrong.  I
just thought this would be a good time to point out the other list!

Cheers

Phil

Abhijit Halder | 1 Aug 2011 12:09
Picon

Re: Query: About process

On Mon, Aug 1, 2011 at 3:35 PM, Phil Muldoon <pmuldoon <at> redhat.com> wrote:
> Abhijit Halder <abhijit.k.halder <at> gmail.com> writes:
>
>> Hi,
>>
>> I am pretty new in this community. Just curious to know whether I will
>> get any notification if my patch get accepted or rejected.
>
> Your patch will get reviewed (by anybody, but normally by a
> maintainer).  They may require changes to the patch.
>
> Only a maintainer can grant you approval to commit your patch.  The
> CONTRIBUTE file in the gdb/ source directory gives a good overview.
>
> Sometimes, patches can be missed.  I generally "ping" patches after a
> week if no review has been forthcoming.  Sometimes the maintainer
> work-load is very high, so some things get missed/forgotten.  It is
> perfectly acceptable to "ping" a patch after a reasonable time, and you
> will not be breaking any etiquette by doing so.
>
> Finally, questions like this generally go to gdb <at> sourceware.org, and
> patch discussion about actual patches to gdb-patches <at> sourceware.org.
> These rules are very loosely applied, so you have done nothing wrong.  I
> just thought this would be a good time to point out the other list!
>
> Cheers
>
> Phil
>

(Continue reading)

Tristan Gingold | 1 Aug 2011 16:06
Favicon

[darwin/committed]: Adjust assertion condition

Hi,

this patch relaxes a too strict assertion condition.  The failure case is explained in the comment.

Committed on trunk.

Tristan.

2011-08-01  Tristan Gingold  <gingold <at> adacore.com>

	* darwin-nat.c (darwin_decode_exception_message): Adjust assertion.

Index: darwin-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/darwin-nat.c,v
retrieving revision 1.26
diff -c -r1.26 darwin-nat.c
*** darwin-nat.c	1 Jul 2011 18:36:28 -0000	1.26
--- darwin-nat.c	1 Aug 2011 14:03:45 -0000
***************
*** 615,622 ****
      return -1;
    *pthread = thread;

    /* Finish decoding.  */
-   gdb_assert (thread->msg_state == DARWIN_RUNNING);
    thread->event.header = *hdr;
    thread->event.thread_port = thread_port;
    thread->event.task_port = task_port;
--- 615,625 ----
(Continue reading)

Matt Rice | 1 Aug 2011 16:08
Picon

Re: [patch] python prompt additions at first prompt.

On Mon, Aug 1, 2011 at 2:50 AM, Phil Muldoon <pmuldoon <at> redhat.com> wrote:
> Matt Rice <ratmice <at> gmail.com> writes:
>
>> little bug with the new python prompt stuff, the prompt_hook doesn't
>> take effect until the second prompt.
>
> Thanks for doing this.  This looks fine to me, apart from one question.
>
> For tests, there are prompt tests in the python.exp file for prompt
> substitutions.  For passing arguments to GDB at start-up, see usage of
> $GDBFLAGS in the testsuite.

I'd tried that, but didn't have much luck,
i'll give it another shot.

>> -     prompt, otherwise just print the prompt.  */
>> -  if (async_command_editing_p)
>> -    {
>> -      int length;
>> -      char *a_prompt;
>> -      char *gdb_prompt = get_prompt (0);
>> -
>> -      /* Tell readline what the prompt to display is and what function
>> -         it will need to call after a whole line is read.  This also
>> -         displays the first prompt.  */
>> -      length = strlen (get_prefix (0))
>> -     + strlen (gdb_prompt) + strlen (get_suffix(0)) + 1;
>> -      a_prompt = (char *) alloca (length);
>> -      strcpy (a_prompt, get_prefix (0));
>> -      strcat (a_prompt, gdb_prompt);
(Continue reading)

Phil Muldoon | 1 Aug 2011 16:13
Picon
Favicon

Re: [patch] python prompt additions at first prompt.

Matt Rice <ratmice <at> gmail.com> writes:

> On Mon, Aug 1, 2011 at 2:50 AM, Phil Muldoon <pmuldoon <at> redhat.com> wrote:
>> Matt Rice <ratmice <at> gmail.com> writes:
>>
>>> little bug with the new python prompt stuff, the prompt_hook doesn't
>>> take effect until the second prompt.
>>
>> Thanks for doing this.  This looks fine to me, apart from one question.
>>
>> For tests, there are prompt tests in the python.exp file for prompt
>> substitutions.  For passing arguments to GDB at start-up, see usage of
>> $GDBFLAGS in the testsuite.
>
> I'd tried that, but didn't have much luck,
> i'll give it another shot.

Look at gdb.base/args.exp

You may not be declaring GDBFLAGS as global.

>> display_gdb_prompt removes any handler that is present, and then
>> installs a handler.  As this is the first prompt, the above code does
>> not (because there could not have been a handler installed).  I think
>> attempting to remove a handler that does not exist just results in a
>> NOOP, but it is worth checking.  I know very little about readline,
>> however.  So my question is: with GDB's copy of readline, is this okay?
>
> Yes, the effect of it seems to turn zero's into zero's.
> by my reading and valgrind, it seems fine,
(Continue reading)

Tom Tromey | 1 Aug 2011 16:24
Picon
Favicon

Re: [patch] Fix for crash printing NaN (PR gdb/13045)

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov <at> google.com> writes:

Paul> Attached patch fixes gdb crash in PR 13045, which (AFAICT) has been broken
Paul> since forever.

Paul> Tested on Linux/x86_64 and Linux/i686 (CC_FOR_TARGET="gcc -m32"); no
Paul> regressions.

Paul> One thing I am not sure about is whether some platforms will cause
Paul> inferior to crash on divide-by-zero (the test will fail on such
Paul> platforms).

I wouldn't worry about it.
If such a platform turns up we can figure out how to fix it then.

This patch is ok.

Tom

Tom Tromey | 1 Aug 2011 16:34
Picon
Favicon

Re: [patch 2/2] Mostly code cleanup: stack.c: TRY_CATCH simplifications

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

Jan> after [patch 1/2] some constructs become obviously redundant.

FWIW, I like both these patches.

Jan> This is a "code cleanup" except for the RETURN_MASK_ALL change.  I haven't
Jan> found any specific reason in the mail thread introducing it and neither any
Jan> reason in the current code, IMO it was only a mistake.

I looked at it, and I agree.

Tom


Gmane