headers
Joel Brobecker | 1 Jul 2010 01:14
Favicon

[commit] Fix build failure with Python installed in non-system location.

Hello,

The debugger fails to build when configure with --python-python=<path>
where <path> is a non-system location.  The reason is a warning made
fatal due to the definition of _XOPEN_SOURCE inside pyconfig.h.  This
is exactly the same problem as with _POSIX_C_SOURCE, handled in
python-internal.h as follow:

| /* /usr/include/features.h on linux systems will define _POSIX_C_SOURCE
|    if it sees _GNU_SOURCE (which config.h will define).
|    pyconfig.h defines _POSIX_C_SOURCE to a different value than
|    /usr/include/features.h does causing compilation to fail.
|    To work around this, undef _POSIX_C_SOURCE before we include Python.h.  */
| #undef _POSIX_C_SOURCE

This patch fixes this problem the same way.  We discussed the problem on
IRC, and talked about using -isystem to provide the location of the Python
includes, and eventually just decided that it was better to just keep it
simple.

2010-06-30  Joel Brobecker  <brobecker <at> adacore.com>

        * python/python-internal.h (_XOPEN_SOURCE): Undefine before
        including Python.h.

Tested on x86_64-linux (I removed -Werror, allowing me to build and run
the testsuite without this patch first). No regression.

Checked in.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hui Zhu | 1 Jul 2010 09:12
Picon
Gravatar

[RFA/DOC] record pic

Hi Eli,

This is the patch to add the "record pic" to the gdb.texinfo and NEWS.
Please help me review it.

Thanks,
Hui

2010-07-01  Hui Zhu  <teawater <at> gmail.com>

	* gdb.texinfo: (Process Record and Replay): Add documentation
	for command "record pic".

---
 NEWS            |   18 ++++++++++++++++
 doc/gdb.texinfo |   62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 80 insertions(+)

--- a/NEWS
+++ b/NEWS
 <at>  <at>  -118,6 +118,24  <at>  <at>  qRelocInsn

 * New commands

+record pic [<FILENAME>]
+  Save the execution log to a vcg file.
+
+set record pic type line|function
+  Set or show the type of the nodes that `record pic' saved.
+
(Continue reading)

Permalink | Reply | 17 comments |
headers
Pedro Alves | 1 Jul 2010 12:41

Re: Static tracepoints support

On Wednesday 30 June 2010 19:16:09, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro <at> codesourcery.com>

> > Here's a new version of the patch integrating all of the
> > above.  Any further comments?
> 
> Just three:
> 
> > +  $_sdata internal variable.  When analying the trace buffer, you can
>                                       ^^^^^^^^
> A typo (sorry I didn't catch that before).
> 
> > +Whether the breakpoint is marked to be disabled or deleted when hit.
> 
> Wasn't there supposed to be an  <at> item before this sentence?

Arrh, copy&paste from "info breakpoints".. the sentence wasn't even
supposed to be there, I've removed it (it's describing breakpoint's
dispositions).

> 
> > +UST backend, this is the the format string passed as argument to the
>                             ^^^
> Redundant "the".
> 
> Okay with those changes.

Checked in with those changes.  Thank you for the review!

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pedro Alves | 1 Jul 2010 14:42

collecting optimized out variables regression (Re: RFA: rewrite dwarf->ax translator (Was: RFC: implement DW_OP_bit_piece))

Hi Tom,

After the rewrite, I'm seeing this:

 (gdb) p m
 $1 = <value optimized out>
 (gdb) maint agent m
  ../../src/gdb/utils.c:1363: internal-error: virtual memory exhausted: can't allocate
562945039736192 bytes.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) 

#0  internal_error (file=0x7531ac "../../src/gdb/utils.c", line=1363, 
    string=0x753568 "virtual memory exhausted: can't allocate %ld bytes.") at ../../src/gdb/utils.c:1162
#1  0x0000000000417464 in nomem (size=562949953380224) at ../../src/gdb/utils.c:1363
#2  0x00000000004174c3 in xmalloc (size=562949953380224) at ../../src/gdb/utils.c:1394
#3  0x00000000005b1ac7 in compile_dwarf_to_ax (expr=0xebd020, loc=0x7fffffffd9b0, arch=0xcc9a20,
addr_size=8, 
    op_ptr=0x0, op_end=0x7fffffffd7e0 " \320\353", per_cu=0xcada90) at ../../src/gdb/dwarf2loc.c:1220
#4  0x00000000005b4b78 in loclist_tracepoint_var_ref (symbol=0xd22c30, gdbarch=0xcc9a20,
ax=0xebd020, 
    value=0x7fffffffd9b0) at ../../src/gdb/dwarf2loc.c:2572
#5  0x000000000048be46 in gen_var_ref (gdbarch=0xcc9a20, ax=0xebd020, value=0x7fffffffd9b0, var=0xd22c30)
    at ../../src/gdb/ax-gdb.c:713
#6  0x000000000048e570 in gen_expr (exp=0xed5280, pc=0x7fffffffd9c8, ax=0xebd020, value=0x7fffffffd9b0)
    at ../../src/gdb/ax-gdb.c:1962
#7  0x000000000048f92a in gen_trace_for_expr (scope=4197499, expr=0xed5280) at ../../src/gdb/ax-gdb.c:2387
#8  0x000000000048fabc in agent_command (exp=0xb4821c "m", from_tty=1) at ../../src/gdb/ax-gdb.c:2456
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pedro Alves | 1 Jul 2010 15:49

el vs ell (Re: Static tracepoints support)

On Monday 28 June 2010 13:26:38, Pedro Alves wrote:
> > > +query), until the target responds with  <at> samp{l} (lower-case el, for
> > > + <at> dfn{last}).                                                ^^
> > 
> > "ell"
> 
> Thanks.  This was copied from elsewhere.  I'll audit those as well
> after this is in.
> 

As promised..  There is only one other instance of "el" or "ell" in
the manuals or sources I could find (cd gdb; egrep  " el(l)?(,|\.| )" * -rn),
and it was the one I copied from.  I was going to fix it, but, I noticed
that <http://en.wikipedia.org/wiki/L> says:

 "L is the twelfth letter of the basic modern Latin alphabet. Its name in
 English (play /ˈɛl/) is spelled el or occasionally ell.[1]"

So, which one should we use?  Is this an American English vs other
flavours issue?

--

-- 
Pedro Alves
Permalink | Reply | 3 comments |
headers
Pedro Alves | 1 Jul 2010 16:00

Re: Static tracepoints support

On Monday 28 June 2010 13:26:38, Pedro Alves wrote:
> > > +with that name. With no LOCATION, uses current execution address of \n\
> > > +selected stack frame.\n\
> > 
> > "of the selected stack frame"
> 
> Fixed.  Needs fixing in BREAK_ARGS_HELP; it's showing up in the help
> strings of all breakpoint commands.
> 

Here's the fix for all other breakpoint commands, but I do
note some sort of pattern here: it appears that "the" was
avoided on purpose in all the sentences as can be seen in
the contenxt of the patch.  Would you like to review
the whole help string, or is this correct?

--

-- 
Pedro Alves

2010-07-01  Pedro Alves  <pedro <at> codesourcery.com>

	* breakpoint.c (BREAK_ARGS_HELP): Add missing `the'.

---
 gdb/breakpoint.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: src/gdb/breakpoint.c
===================================================================
--- src.orig/gdb/breakpoint.c	2010-07-01 14:51:37.000000000 +0100
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pedro Alves | 1 Jul 2010 16:15

add a few index entries (Re: Static tracepoints support)

On Monday 28 June 2010 13:26:38, Pedro Alves wrote:
> > > + <at> cindex set static tracepoint
> > 
> > This index entry would be much more efficient if it did not start with
> > "set".  For example,
> > 
> >    <at> cindex static tracepoint, setting
> 
> Agreed.  I see the same could be done to set fast tracepoint.  I'll
> see about auditing that and others after this patch is in.

Can't say I see that much consistency, but, reading the generated
index, these appear to me to increase usefulness.  Okay?

--

-- 
Pedro Alves

2010-07-01  Pedro Alves  <pedro <at> codesourcery.com>

	* gdb.texinfo (Create and Delete Tracepoints): Add more index
	entries for fast tracepoints and static tracepoints.

---
 gdb/doc/gdb.texinfo |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: src/gdb/doc/gdb.texinfo
===================================================================
--- src.orig/gdb/doc/gdb.texinfo	2010-07-01 15:02:17.000000000 +0100
+++ src/gdb/doc/gdb.texinfo	2010-07-01 15:08:11.000000000 +0100
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pedro Alves | 1 Jul 2010 16:22

clarify "help break" output a bit (Re: Static tracepoints support)

On Wednesday 30 June 2010 19:16:09, Eli Zaretskii wrote:
> > > But only if the conditionals are different.
> > > 
> > > Anyway, it confused me, so perhaps it's a good idea to clarify.
> > 
> > Okay, I agree, though I'd prefer to do that as a follow up, where I
> > change both the break- and tracepoint command's help output at once.
> > Is that okay with you?
> 
> Yes.

Thanks.  Here's a patch.  Okay?

--

-- 
Pedro Alves

2010-07-01  Pedro Alves  <pedro <at> codesourcery.com>

	* breakpoint.c (BREAK_ARGS_HELP, _initialize_breakpoint): Clarify
	usefulness suggestion of multiple breakpoints at same location.

---
 gdb/breakpoint.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Index: src/gdb/breakpoint.c
===================================================================
--- src.orig/gdb/breakpoint.c	2010-07-01 15:16:13.000000000 +0100
+++ src/gdb/breakpoint.c	2010-07-01 15:17:29.000000000 +0100
 <at>  <at>  -11502,7 +11502,8  <at>  <at>  stack frame.  This is useful for breakin
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thiago Jung Bauermann | 1 Jul 2010 16:50
Picon

Re: [PATCH 2/4] Hardware accelerated watchpoint conditions

Hi,

On Wed, 2010-06-23 at 21:57 +0200, Ulrich Weigand wrote:
> Thiago Jung Bauermann wrote:
> > +  /* The size of the user-provided data value matters because the value is
> > +     "left-aligned" within DATA_VALUE, e.g: a 1-byte data type will occupy the
> > +     first byte of DATA_VALUE, a two-byte data type the first two, and so on.
> 
> Well, but that's only because you arranged the value in that weird way
> in the first place :-)   See check_condition below:
>   *data_value = value_as_long (val);
>   *data_value_len = TYPE_LENGTH (value_type (val));
>   *data_value = *data_value << (sizeof (CORE_ADDR) - *data_value_len) * 8;

That was true when using memcpy instead of value_as_long, and I thought
that keeping it that way made things simpler for calculate_dvc. It turns
out that I was wrong.

> > +  if (data_value_len - len > align_offset)
> > +    /* The user-provided value type is larger than the watched value type,
> > +       and it is also to the right of the offset within the DVC register
> > +       where it should be.  */
> > +    *condition_value = (uint64_t) data_value << (data_value_len - len
> > +						 - align_offset) * 8;
> > +  else
> > +    /* The user-provided value type is either smaller than the watched
> > +       value type, or else it is equal or larger than the watched value
> > +       type but to the left of the offset within the DVC register where
> > +       it should be.  */
> > +    *condition_value = (uint64_t) data_value >> (align_offset
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tom Tromey | 1 Jul 2010 17:20
Picon
Favicon

FYI: fix pieces.exp failure

I'm checking this in.

Yesterday Doug pointed out that one of the new pieces.exp tests was
failing.  I tracked this down to a missing "!" -- oops.

This patch fixes the bug.  I also renamed the field in lval_funcs,
because the old name was actively misleading.

Built and regtested on x86-64 (compile farm).
I also ran pieces.exp locally, since it isn't actually tested on x86-64.

Tom

2010-07-01  Tom Tromey  <tromey <at> redhat.com>

	* value.h (struct lval_funcs) <check_any_valid>: Rename from
	check_all_valid.
	* value.c (value_entirely_optimized_out): Invert result.  Update
	for new function name.

Index: value.c
===================================================================
RCS file: /cvs/src/src/gdb/value.c,v
retrieving revision 1.106
diff -u -r1.106 value.c
--- value.c	28 Jun 2010 21:16:02 -0000	1.106
+++ value.c	1 Jul 2010 15:18:16 -0000
 <at>  <at>  -521,7 +521,7  <at>  <at> 
   if (value->lval != lval_computed
       || !value->location.computed.funcs->check_validity)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane