headers
Mike Frysinger | 1 Jul 2011 02:19
Picon
Favicon
Gravatar

Re: [PATCH v3] gdb: tests: set remotetimeout to gdb_load_timeout for remote targets

On Thu, Jun 30, 2011 at 18:54, Joel Brobecker wrote:
>> v3
>>       - add comments to new helper funcs
>>       - use gdb_test_multiple
>>
>>  gdb/testsuite/config/monitor.exp |   16 +++++++++++++++-
>>  gdb/testsuite/lib/gdb.exp        |   27 +++++++++++++++++++++++++++
>>  2 files changed, 42 insertions(+), 1 deletions(-)
>
> This version is OK.  You forgot to provide a ChangeLog and I forgot
> to remind you about that....

committed with:
2011-06-30  Jie Zhang <jie.zhang <at> analog.com>
            Mike Frysinger  <vapier <at> gentoo.org>

        * config/monitor.exp (get_remotetimeout, set_remotetimeout): New
        helper functions for getting/setting remotetimeout variable.
        * lib/gdb.exp (gdb_load): If the target is remote, set
        $oldremotetimeout to get_remotetimeout, then call set_remotetimeout
        with $loadtimeout.  Set $load_ok to 0 before doing the load.
        Instead of returning, immediately, set $load_ok to 0.  Call
        set_remotetimeout with $oldremotetimeout, and then return if
        $load_ok is 1.
-mike
Permalink | Reply | 0 comments |
headers
Mike Frysinger | 1 Jul 2011 02:24
Picon
Favicon
Gravatar

[PATCH/RFC] gdb: tests: add support for testing FLAT toolchains

From: Jie Zhang <jie <at> codesourcery.com>

FLAT toolchains output a FLAT binary for the named output and create
another file with a .gdb suffix that is used for debugging.  So when
testing a FLAT toolchain and we need to load up a file, use the .gdb.

This restarts an old thread and implements things as suggested by
Daniel Jacobowitz:
http://sourceware.org/ml/gdb-patches/2010-03/msg00648.html

Pretty sure this works (I'll double check), but I want to make sure
this is going in the direction people are OK with.

Signed-off-by: Jie Zhang <jie <at> codesourcery.com>
Signed-off-by: Mike Frysinger <vapier <at> gentoo.org>
---
 gdb/testsuite/lib/gdb.exp |   22 +++++++++++++++++++++-
 1 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index dc16cfa..091b271 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
 <at>  <at>  -2091,6 +2091,16  <at>  <at>  proc current_target_name { } {
     return $answer
 }

+proc gdb_get_exec_name { binfile } {
+    # FLAT toolchains have to load the .flt file to the board
+    if { [target_info exists use_binfmt_flat]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yao Qi | 1 Jul 2011 04:02
Gravatar

Re: FYI: more cleanup fixes

On 07/01/2011 03:29 AM, Tom Tromey wrote:
> I neglected to mention in the last email: if anybody wants the latest
> version of the plugin, just let me know.

Tom, I'd like to have a try on this plugin.  How can I get it?

--

-- 
Yao (齐尧)
Permalink | Reply | 1 comment |
headers
Taisuke Yamada | 1 Jul 2011 06:00

[PATCH] sys.argv and ipython (interactive python) support in GDB/Python

Hi.

While working with GDB/Python, I wondered if I can use it
interactively by loading ipython (interactive python shell) on
top of it. However, current GDB/Python fails as it does not
initialize sys.argv properly.

So here is a patch to set sys.argv when initializing embedded
Python interpreter. I have tested it by running ipython with

  (gdb) python execfile("/usr/bin/ipython")
  Python 2.6.6 (r266:84292, Oct  9 2010, 12:40:51)
  ...
  In [1]: import gdb
  In [2]: print gdb.lookup_symbol("main")
  (<gdb.Symbol object at 0x7ff6f9815b20>, False)

It is quite nice to be able to inspect debuggee interactively
using full-featured language.

This patch should also improve compatibility with other exsiting
python libraries, as some of those expect existance of sys.argv.

Best Regards,
Attachment (gdb-python-ipython.patch): text/x-patch, 434 bytes
Permalink | Reply | 5 comments |
headers
Richard Earnshaw | 1 Jul 2011 10:59
Favicon

Re: [PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703)

On 29/06/11 11:00, Yao Qi wrote:
> On 06/29/2011 04:47 PM, Terry Guo wrote:
>> Hi,
>>
>> First if you look at the generated binary code, I thought it is a valid case. After performing the function
test, it will fall into function bar which is a normal function. At least my case can run correctly on QEMU.
It is very likely for people to write program in assembly code like:
>>
>> main:
>>     b test
>>
>> test:
>>     movs r5, #10
>> bar:
>>     push.......
>>     .........
>>
> 
> We are lucky here GCC places bar next to function test physically, but
> gcc may also place function test and bar in other layout, like
> 
> main:
> 	b test
> 
> bar:
> 	push ...
> 
> test:
> 	moves r5, #10
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pedro Alves | 1 Jul 2011 11:16

Re: [PATCH/RFC] gdb: tests: add support for testing FLAT toolchains

On Friday 01 July 2011 01:24:41, Mike Frysinger wrote:
> From: Jie Zhang <jie <at> codesourcery.com>
> 
> FLAT toolchains output a FLAT binary for the named output and create
> another file with a .gdb suffix that is used for debugging.  So when
> testing a FLAT toolchain and we need to load up a file, use the .gdb.

Sounds a lot like the recently added
lib/gdb.exp:exec_target_file/exec_symbol_file hooks?  We added them
to solve the exact same problem.  We then have this in our board file
for uclinux/flat toolchains:

       proc exec_target_file { binfile } {
           return ${binfile}.flt
       }

--

-- 
Pedro Alves
Permalink | Reply | 6 comments |
headers
Pedro Alves | 1 Jul 2011 11:46

Re: [PATCH] Fix that different function breakpoints are set at same pc address (PR gdb/12703)

On Friday 01 July 2011 09:59:07, Richard Earnshaw wrote:
> On 29/06/11 11:00, Yao Qi wrote:
> > On 06/29/2011 04:47 PM, Terry Guo wrote:
> >> Hi,
> >>
> >> First if you look at the generated binary code, I thought it is a valid case. After performing the
function test, it will fall into function bar which is a normal function. At least my case can run correctly
on QEMU. It is very likely for people to write program in assembly code like:
> >>
> >> main:
> >>     b test
> >>
> >> test:
> >>     movs r5, #10
> >> bar:
> >>     push.......
> >>     .........
> >>
> > 
> > We are lucky here GCC places bar next to function test physically, but
> > gcc may also place function test and bar in other layout, like
> > 
> > main:
> > 	b test
> > 
> > bar:
> > 	push ...
> > 
> > test:
> > 	moves r5, #10
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pedro Alves | 1 Jul 2011 11:51

Re: [patch] segmentation fault at gdbserver

Thanks, I'll try to take a look soon.  I suspect there
may be something more to this, though.

-- 
Pedro Alves

On Monday 27 June 2011 18:18:11, Liang Cheng wrote:
> Hi Pedro,
> 
> Can you please review this change?
> thanks
> Liang
> 
> 2011-06-27  Liang Cheng  <liang.cheng555 <at> gmail.com>
> 
> 	* tracepoint.c (cmd_qtstatus):  Check whether current_inferior is NULL.
> 
> 
> --- tracepoint.c.orig   2011-05-12 07:09:18.000000000 -0500
> +++ tracepoint.c        2011-06-22 14:05:13.553993630 -0500
>  <at>  <at>  -3159,7 +3159,7  <at>  <at> 
>    trace_debug ("Returning trace status as %d, stop reason %s",
>                tracing, tracing_stop_reason);
> 
> -  if (in_process_agent_loaded ())
> +  if (in_process_agent_loaded () && current_inferior != NULL)
>      {
>        pause_all (1);
> 
> On Fri, Jun 24, 2011 at 5:15 PM, Liang Cheng <liang.cheng555 <at> gmail.com> wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Pouget | 1 Jul 2011 12:31
Picon
Gravatar

Re: [PATCH] sys.argv and ipython (interactive python) support in GDB/Python

hello,

just one thing, you're patch doesn't compile on my computer because of this line

+  char *argv[] = { "gdb", NULL };
error: ISO C90 forbigs mixed declarations and code

but ipython looks very intersting, thanks!

Kevin

On Fri, Jul 1, 2011 at 6:00 AM, Taisuke Yamada <tai <at> rakugaki.org> wrote:
>
> Hi.
>
> While working with GDB/Python, I wondered if I can use it
> interactively by loading ipython (interactive python shell) on
> top of it. However, current GDB/Python fails as it does not
> initialize sys.argv properly.
>
> So here is a patch to set sys.argv when initializing embedded
> Python interpreter. I have tested it by running ipython with
>
>  (gdb) python execfile("/usr/bin/ipython")
>  Python 2.6.6 (r266:84292, Oct  9 2010, 12:40:51)
>  ...
>  In [1]: import gdb
>  In [2]: print gdb.lookup_symbol("main")
>  (<gdb.Symbol object at 0x7ff6f9815b20>, False)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phil Muldoon | 1 Jul 2011 12:59
Picon
Favicon

Re: [PATCH] sys.argv and ipython (interactive python) support in GDB/Python

Taisuke Yamada <tai <at> rakugaki.org> writes:

Thanks for the patch!

> diff --git a/gdb/python/python.c b/gdb/python/python.c
> index 90d5dc8..c9f2ce9 100644
> --- a/gdb/python/python.c
> +++ b/gdb/python/python.c
>  <at>  <at>  -1010,7 +1010,9  <at>  <at>  Enables or disables printing of Python stack traces."),
>  			     SLASH_STRING, "python", NULL));
>  #endif
>  
> +  char *argv[] = { "gdb", NULL };

As Kevin noted, this needs to be placed in the declarations part of the
function.

>    Py_Initialize ();
> +  PySys_SetArgvEx (1, argv, 0);

This can throw an error.  Though, it seems unlikely it would.  I'm also
a little confused about the documentation about PySys_SetArgvEx.  

"These parameters are similar to those passed to the program's
main() function with the difference that the first entry should refer to
the script file to be executed rather than the executable hosting the
Python interpreter. If there isn't a script that will be run,
the first entry in argv can be an empty string. If this function fails
to initialize sys.argv, a fatal condition is signalled using
Py_FatalError()."
(Continue reading)

Permalink | Reply | 3 comments |

Gmane