headers
Jim Blandy | 1 Dec 2007 01:55

Re: [patch] Parse DW_AT_ranges into PSYMTABS (for childless CU, for vDSO32)


Daniel Jacobowitz <drow at false.org> writes:
> On Fri, Nov 30, 2007 at 12:10:21PM +0100, Jan Kratochvil wrote:
>> It was not reproducible for me but the problem is Vladimir's i386 crti.S has
>> DW_AT_ranges which overlap the main code (due to its .fini part).  The main
>> code full-symbols get ignored now due to it.
>> 
>> Going to post a fix (try to load symtab for each matching psymtab?) and an
>> updated testcase.
>
> Jim, can we get your addrmap changes in as they are, instead of
> working on a representation change (which was the state when they were
> briefly discussed, in October)?  After that, it's simple to solve this
> problem more accurately by using addrmaps for symtabs too, not just
> blocks.

Sure, if Joel doesn't object.
Permalink | Reply | 1 comment |
headers
Jim Blandy | 1 Dec 2007 02:38

Re: Variable identification


Michael Snyder <msnyder at specifix.com> writes:
> On Thu, 2007-11-29 at 22:02 +0300, Vladimir Prus wrote:
>> Jim Blandy wrote:
>> 
>> >> This is probably good behaviour, indeed. Or maybe we should not
>> >> disable watchpoint, but mark it as pending, in the same sense of
>> >> "user wanted it to be enabled, but it won't trigger until a shared
>> >> lib is loaded" that is used for ordinary watchpoints.
>> > 
>> > I think so, too.  I guess the key observation is that, while it's not
>> > meaningful to talk about a particular local variable "coming back
>> > alive", since each function call creates a distinct set of local
>> > variables, and you can have recursion, etc., it is meaningful to talk
>> > about a shared library being reloaded, and it's intuitive to identify
>> > the 'X' from the first loading with the 'X' in the second loading,
>> > even if they're at different addresses.
>> 
>> Yes. I now recall this is more general problem with identification of
>> variables in GDB. Say, you're in function, and you have local variable
>> 'foo'. In GUI, you do something with 'foo' -- set display format to
>> hex, expand it, and so on. It's highly desirable to keep this
>> information for the next run of program, or even next run of the GUI --
>> even if variable is local, it's not likely that the display properties
>> user wants depend on frame.
>> 
>> Unfortunately, there's no way to do that.
>
> I haven't followed the discussion closely, but
> shouldn't it be up to the GUI to keep such persistant
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Snyder | 1 Dec 2007 02:34

Re: Variable identification

On Fri, 2007-11-30 at 17:38 -0800, Jim Blandy wrote:
> Michael Snyder <msnyder at specifix.com> writes:
> > On Thu, 2007-11-29 at 22:02 +0300, Vladimir Prus wrote:
> >> Jim Blandy wrote:
> >> 
> >> >> This is probably good behaviour, indeed. Or maybe we should not
> >> >> disable watchpoint, but mark it as pending, in the same sense of
> >> >> "user wanted it to be enabled, but it won't trigger until a shared
> >> >> lib is loaded" that is used for ordinary watchpoints.
> >> > 
> >> > I think so, too.  I guess the key observation is that, while it's not
> >> > meaningful to talk about a particular local variable "coming back
> >> > alive", since each function call creates a distinct set of local
> >> > variables, and you can have recursion, etc., it is meaningful to talk
> >> > about a shared library being reloaded, and it's intuitive to identify
> >> > the 'X' from the first loading with the 'X' in the second loading,
> >> > even if they're at different addresses.
> >> 
> >> Yes. I now recall this is more general problem with identification of
> >> variables in GDB. Say, you're in function, and you have local variable
> >> 'foo'. In GUI, you do something with 'foo' -- set display format to
> >> hex, expand it, and so on. It's highly desirable to keep this
> >> information for the next run of program, or even next run of the GUI --
> >> even if variable is local, it's not likely that the display properties
> >> user wants depend on frame.
> >> 
> >> Unfortunately, there's no way to do that.
> >
> > I haven't followed the discussion closely, but
> > shouldn't it be up to the GUI to keep such persistant
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Blandy | 1 Dec 2007 02:48

Re: Support constants for DW_AT_data_member_location


Vladimir Prus <vladimir at codesourcery.com> writes:
> This is wrong, per DWARF standard:
>
>        Some encodings are members of more than one class; in that case, 
>         the list of classes allowed by the applicable attribute in 
>         Figure 18 determines the class of the form. DW_FORM_data4 and 
>         DW_FORM_data8 may be members of classes constant, lineptr, 
>         loclistptr, macptr and  rangelistptr. They are members of the 
>         class constant if used for the value of an attribute that allows class
>         constant but not class lineptr, loclistptr, macptr or rangelistptr.
>         They are members of the class lineptr, loclistptr, macptr or 
>         rangelistptr if used for the value of an attribute that allows
>         one of those classes.
>
> Referring to Figure 18, I see:
>
>      Attribute name                  Classes
>     DW_AT_data_member_location       block, constant, loclistptr
>
> So, DW_FORM_data4 used for DW_AT_data_member_location is never interepreted
> as constant. Maybe we should have "is_surely_constant" function?

Oh --- great catch, thanks.  (We don't support location lists for
DW_AT_data_member_location yet, but we certainly should warn, not
randomly misinterpret the value.)

How's this, then?

gdb/ChangeLog:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael Snyder | 1 Dec 2007 02:37

Re: RFA: Fix check for no-saved-pc

On Fri, 2007-11-30 at 18:00 -0500, Daniel Jacobowitz wrote:
> On Fri, Nov 30, 2007 at 02:40:31PM -0800, Michael Snyder wrote:
> > There's a check in get_prev_frame to see if the next saved pc
> > is zero.  I think it has an off-by-one error, and is checking 
> > for the pc of the wrong frame.
> 
> Mark K. and I have had roughly a month's worth of discussion on this
> check over the last two years; it's where it is on purpose.  Here's
> the last conversation:
> 
>   http://sourceware.org/ml/gdb-patches/2006-05/msg00196.html
>   http://sourceware.org/ml/gdb-patches/2006-07/msg00296.html

All right.  Then let's leave that test alone, and add another
test, much later on, to detect and report this situation.

Here's my revised patch.  Testsuites un-affected.

As before, the effect of this change is to have gdb print
a more informative message instead of a meaningless zero-frame.

2007-11-30  Michael Snyder  <msnyder <at> specifix.com>

	* frame.c (get_prev_frame): Remove unused local variable.
	(get_prev_frame_1): Check for null saved pc in the calling 
	frame.  Set up stop_reason conditions for printing stop reason.

Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
(Continue reading)

Permalink | Reply | 6 comments |
headers
Pedro Alves | 1 Dec 2007 05:10
Picon
Favicon

Re: [rfc] Remote file transfer support

Daniel Jacobowitz wrote:

--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ gdb/gdbserver/hostio.c	2007-11-30 13:34:40.000000000 -0500
 <at>  <at>  -0,0 +1,517  <at>  <at> 
+/* Host file transfer support for gdbserver.
+   Copyright (C) 2006

Still living in the past, heh?  :-)

--

-- 
Pedro Alves
Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 1 Dec 2007 06:00

Re: [rfc] Remote file transfer support

On Sat, Dec 01, 2007 at 04:10:27AM +0000, Pedro Alves wrote:
> Daniel Jacobowitz wrote:
> 
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ gdb/gdbserver/hostio.c	2007-11-30 13:34:40.000000000 -0500
>  <at>  <at>  -0,0 +1,517  <at>  <at> 
> +/* Host file transfer support for gdbserver.
> +   Copyright (C) 2006
> 
> Still living in the past, heh?  :-)

It's like a foreign country...

Thanks, fixed.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 0 comments |
headers
Vladimir Prus | 1 Dec 2007 12:09

[RFA] Report watchpoints hits for 'debug infrun'.


This patch make 'set debug infrun 1' produce more detailed
information about watchpoint hits. OK?

	* gdb/infrun.c (handle_inferior_event): More
	detailed debugging about watchpoint hit.
---
 gdb/infrun.c |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/gdb/infrun.c b/gdb/infrun.c
index d79ed3f..6c62b60 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
 <at>  <at>  -1597,7 +1597,17  <at>  <at>  handle_inferior_event (struct execution_control_state *ecs)
   stop_pc = read_pc_pid (ecs->ptid);

   if (debug_infrun)
-    fprintf_unfiltered (gdb_stdlog, "infrun: stop_pc = 0x%s\n", paddr_nz (stop_pc));
+    {
+      CORE_ADDR addr;
+      fprintf_unfiltered (gdb_stdlog, "infrun: stop_pc = 0x%s\n", paddr_nz (stop_pc));
+      if (STOPPED_BY_WATCHPOINT (*ws))
+	{
+	  fprintf_unfiltered (gdb_stdlog, "infrun: stopped by watchpoint\n");
+	  fprintf_unfiltered (gdb_stdlog, 
+			      "infrun: stopped data address = 0x%s\n", 
+			      paddr_nz (addr));
+	}
+    }
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vladimir Prus | 1 Dec 2007 12:12

[RFA] Try 3: Use multiple locations for hardware watchpoints.


I've noticed that my previous patch to use multiple locations
for watchpoint causes (non-deterministic) regression on watchthreads.exp,
caused by the fact that we always updated the 'val' field on
watchpoint, and it's possible that if two threads are stopped on
different watchpoints, we'd update the val field of the second watchpoint
while processing the hit of the first one, and then when we get to 
the second watchpoint, we'd decide that the value has not changed.
I think this revision if really final. OK?

- Volodya

	This eliminates the need to traverse value chain, doing
	various checks, in three different places.

	* breakpoint.h (struct bp_location): New fields
	lengths and watchpoint_type.
	(struct breakpoint): Remove the val_chain field.
	* breakpoint.c (is_hardware_watchpoint): New.
	(free_valchain): Remove.
	(update_watchpoint): New.
	(insert_bp_location): For hardware watchpoint, just
	directly insert it.
	(insert_breakpoints): Call update_watchpoint_locations
	on all watchpoints.  If we have failed to insert
	any location of a hardware watchpoint, remove all inserted
	locations.
	(remove_breakpoint): For hardware watchpoints, directly
	remove location.
	(watchpoints_triggered): Iterate over locations.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Vladimir Prus | 1 Dec 2007 12:19

[RFA] Ignore breakpoints when reading memory.


This commit prepares us for always-inserted-breakpoints mode.
If breakpoints are always inserted, then reading the code memory
will read the breakpoint instructions, not the original content.
This patch makes us try to restore the original comments using
the breakpoints table. OK?

- Volodya

	* breakpoint.h (breakpoint_restore_shadows): New
	declaration.
	* breakpoint.c (breakpoint_restore_shadows): New.
	(read_memory_nobpt): Use breakpoint_restore_shadows.
	* target.c (memory_xfer_partial): Call
	breakpoint_restore_shadows.
---
 gdb/breakpoint.c |   80 ++++++++++++++++++++++-------------------------------
 gdb/breakpoint.h |    4 +++
 gdb/target.c     |   13 +++++++--
 3 files changed, 47 insertions(+), 50 deletions(-)

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 59fec71..4365a3a 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
 <at>  <at>  -713,14 +713,23  <at>  <at>  commands_from_control_command (char *arg, struct command_line *cmd)
 int
 read_memory_nobpt (CORE_ADDR memaddr, gdb_byte *myaddr, unsigned len)
 {
-  int status;
(Continue reading)

Permalink | Reply | 9 comments |

Gmane