RFC: remove gdbarch from struct breakpoint

RFC: remove gdbarch from struct breakpoint

[Tom Tromey]

I would appreciate comments on this patch.

This is the first of two patches in preparation for my "ambiguous
linespec" patch.  I think they are reasonably independent so I am
sending them separately.

This patch removes the 'gdbarch' field from struct breakpoint.

In most cases, it is sufficient to replace the use of this field with
the location's gdbarch instead.  In fact, I think the cases in
tracepoint.c where this is not done are probably latent bugs.

Looking again at the patch I am not totally sure that there is not a
subtle dependency here on the ambiguous linespec patch -- maybe the
assertion in add_location_to_breakpoint is not always valid without some
linespec changes.  I won't check this in until the whole series is ready
to avoid any doubt.

Built and regtested on x86-64 F15.

Tom

b/gdb/ChangeLog:
2011-10-27  Tom Tromey  <tromey@redhat.com>

	* tracepoint.c (encode_actions_1): Use the location's gdbarch.
	(encode_actions): Likewise.
	* python/py-breakpoint.c (gdbpy_should_stop)
	(gdbpy_breakpoint_has_py_cond): Update.
	* breakpoint.h (struct breakpoint) <gdbarch>: Remove field.
	* breakpoint.c (print_one_breakpoint_location): Use location's
	gdbarch.
	(init_raw_breakpoint_without_location): Remove gdbarch argument.
	(set_raw_breakpoint_without_location): Likewise.
	(get_sal_arch): Use find_pc_section as a fallback.
	(init_raw_breakpoint, momentary_breakpoint_from_master)
	(add_location_to_breakpoint, create_breakpoint, watch_command_1):
	Update.

From f52366f687f5e191fcbff3598f50ffc11a2b28e3 Mon Sep 17 00:00:00 2001
From: Tom Tromey <tromey@redhat.com>
Date: Thu, 6 Oct 2011 08:10:07 -0600
Subject: [PATCH 1/3] remove gdbarch from struct breakpoint

---
 gdb/ChangeLog              |   16 ++++++++++++++++
 gdb/breakpoint.c           |   33 +++++++++++++++++----------------
 gdb/breakpoint.h           |    2 --
 gdb/python/py-breakpoint.c |    5 ++---
 gdb/tracepoint.c           |   16 ++++++++--------
 5 files changed, 43 insertions(+), 29 deletions(-)

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index ba1b08f..3ae7508 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -106,8 +106,7 @@ static void break_command_1 (char *, int, int);
 
 static void mention (struct breakpoint *);
 
-static struct breakpoint *set_raw_breakpoint_without_location (struct gdbarch *,
-							       enum bptype,
+static struct breakpoint *set_raw_breakpoint_without_location (enum bptype,
 							       const struct breakpoint_ops *);
 /* This function is used in gdbtk sources and thus can not be made
    static.  */
@@ -4861,7 +4860,7 @@ print_one_breakpoint_location (struct breakpoint *b,
       /* FIXME: cagney/2002-12-01: Shouldn't be poking around inside
          the frame ID.  */
       ui_out_field_core_addr (uiout, "frame",
-			      b->gdbarch, b->frame_id.stack_addr);
+			      loc->gdbarch, b->frame_id.stack_addr);
       ui_out_text (uiout, "\n");
     }
   
@@ -5678,7 +5677,6 @@ add_to_breakpoint_chain (struct breakpoint *b)
 
 static void
 init_raw_breakpoint_without_location (struct breakpoint *b,
-				      struct gdbarch *gdbarch,
 				      enum bptype bptype,
 				      const struct breakpoint_ops *ops)
 {
@@ -5688,7 +5686,6 @@ init_raw_breakpoint_without_location (struct breakpoint *b,
 
   b->ops = ops;
   b->type = bptype;
-  b->gdbarch = gdbarch;
   b->language = current_language->la_language;
   b->input_radix = input_radix;
   b->thread = -1;
@@ -5707,13 +5704,12 @@ init_raw_breakpoint_without_location (struct breakpoint *b,
    that has type BPTYPE and has no locations as yet.  */
 
 static struct breakpoint *
-set_raw_breakpoint_without_location (struct gdbarch *gdbarch,
-				     enum bptype bptype,
+set_raw_breakpoint_without_location (enum bptype bptype,
 				     const struct breakpoint_ops *ops)
 {
   struct breakpoint *b = XNEW (struct breakpoint);
 
-  init_raw_breakpoint_without_location (b, gdbarch, bptype, ops);
+  init_raw_breakpoint_without_location (b, bptype, ops);
   add_to_breakpoint_chain (b);
   return b;
 }
@@ -5767,11 +5763,17 @@ set_breakpoint_location_function (struct bp_location *loc, int explicit_loc)
 static struct gdbarch *
 get_sal_arch (struct symtab_and_line sal)
 {
+  struct obj_section *sect;
+
   if (sal.section)
     return get_objfile_arch (sal.section->objfile);
   if (sal.symtab)
     return get_objfile_arch (sal.symtab->objfile);
 
+  sect = find_pc_section (sal.pc);
+  if (sect)
+    return get_objfile_arch (sect->objfile);
+
   return NULL;
 }
 
@@ -5791,11 +5793,11 @@ init_raw_breakpoint (struct breakpoint *b, struct gdbarch *gdbarch,
   CORE_ADDR adjusted_address;
   struct gdbarch *loc_gdbarch;
 
-  init_raw_breakpoint_without_location (b, gdbarch, bptype, ops);
+  init_raw_breakpoint_without_location (b, bptype, ops);
 
   loc_gdbarch = get_sal_arch (sal);
   if (!loc_gdbarch)
-    loc_gdbarch = b->gdbarch;
+    loc_gdbarch = gdbarch;
 
   if (bptype != bp_catchpoint)
     gdb_assert (sal.pspace != NULL);
@@ -7049,7 +7051,7 @@ momentary_breakpoint_from_master (struct breakpoint *orig,
 {
   struct breakpoint *copy;
 
-  copy = set_raw_breakpoint_without_location (orig->gdbarch, type, ops);
+  copy = set_raw_breakpoint_without_location (type, ops);
   copy->loc = allocate_bp_location (copy);
   set_breakpoint_location_function (copy->loc, 1);
 
@@ -7128,8 +7130,7 @@ add_location_to_breakpoint (struct breakpoint *b,
     ;
   *tmp = loc;
   loc->gdbarch = get_sal_arch (*sal);
-  if (!loc->gdbarch)
-    loc->gdbarch = b->gdbarch;
+  gdb_assert (loc->gdbarch);
   loc->requested_address = sal->pc;
   loc->address = adjust_breakpoint_address (loc->gdbarch,
 					    loc->requested_address, b->type);
@@ -7991,7 +7992,7 @@ create_breakpoint (struct gdbarch *gdbarch,
 
       make_cleanup (xfree, copy_arg);
 
-      b = set_raw_breakpoint_without_location (gdbarch, type_wanted, ops);
+      b = set_raw_breakpoint_without_location (type_wanted, ops);
       set_breakpoint_number (internal, b);
       b->thread = -1;
       b->addr_string = canonical.canonical[0];
@@ -9327,10 +9328,10 @@ watch_command_1 (char *arg, int accessflag, int from_tty,
   w = XCNEW (struct watchpoint);
   b = &w->base;
   if (use_mask)
-    init_raw_breakpoint_without_location (b, NULL, bp_type,
+    init_raw_breakpoint_without_location (b, bp_type,
 					  &masked_watchpoint_breakpoint_ops);
   else
-    init_raw_breakpoint_without_location (b, NULL, bp_type,
+    init_raw_breakpoint_without_location (b, bp_type,
 					  &watchpoint_breakpoint_ops);
   b->thread = thread;
   b->disposition = disp_donttouch;
diff --git a/gdb/breakpoint.h b/gdb/breakpoint.h
index c2116e2..dba5392 100644
--- a/gdb/breakpoint.h
+++ b/gdb/breakpoint.h
@@ -581,8 +581,6 @@ struct breakpoint
        the end of the range (malloc'd).  */
     char *addr_string_range_end;
 
-    /* Architecture we used to set the breakpoint.  */
-    struct gdbarch *gdbarch;
     /* Language we used to set the breakpoint.  */
     enum language language;
     /* Input radix we used to set the breakpoint.  */
diff --git a/gdb/python/py-breakpoint.c b/gdb/python/py-breakpoint.c
index daceb99..94dbc72 100644
--- a/gdb/python/py-breakpoint.c
+++ b/gdb/python/py-breakpoint.c
@@ -733,7 +733,7 @@ gdbpy_should_stop (struct breakpoint_object *bp_obj)
 
   PyObject *py_bp = (PyObject *) bp_obj;
   struct breakpoint *b = bp_obj->bp;
-  struct gdbarch *garch = b->gdbarch ? b->gdbarch : get_current_arch ();
+  struct gdbarch *garch = get_current_arch ();
   struct cleanup *cleanup = ensure_python_env (garch, current_language);
 
   if (PyObject_HasAttrString (py_bp, stop_func))
@@ -771,8 +771,7 @@ gdbpy_breakpoint_has_py_cond (struct breakpoint_object *bp_obj)
 {
   int has_func = 0;
   PyObject *py_bp = (PyObject *) bp_obj;
-  struct gdbarch *garch = bp_obj->bp->gdbarch ? bp_obj->bp->gdbarch :
-    get_current_arch ();
+  struct gdbarch *garch = get_current_arch ();
   struct cleanup *cleanup = ensure_python_env (garch, current_language);
   
   if (py_bp != NULL)
diff --git a/gdb/tracepoint.c b/gdb/tracepoint.c
index d88fcd7..23f3071 100644
--- a/gdb/tracepoint.c
+++ b/gdb/tracepoint.c
@@ -1321,14 +1321,14 @@ encode_actions_1 (struct command_line *action,
 
 	      if (0 == strncasecmp ("$reg", action_exp, 4))
 		{
-		  for (i = 0; i < gdbarch_num_regs (t->gdbarch); i++)
+		  for (i = 0; i < gdbarch_num_regs (tloc->gdbarch); i++)
 		    add_register (collect, i);
 		  action_exp = strchr (action_exp, ',');	/* more? */
 		}
 	      else if (0 == strncasecmp ("$arg", action_exp, 4))
 		{
 		  add_local_symbols (collect,
-				     t->gdbarch,
+				     tloc->gdbarch,
 				     tloc->address,
 				     frame_reg,
 				     frame_offset,
@@ -1338,7 +1338,7 @@ encode_actions_1 (struct command_line *action,
 	      else if (0 == strncasecmp ("$loc", action_exp, 4))
 		{
 		  add_local_symbols (collect,
-				     t->gdbarch,
+				     tloc->gdbarch,
 				     tloc->address,
 				     frame_reg,
 				     frame_offset,
@@ -1350,7 +1350,7 @@ encode_actions_1 (struct command_line *action,
 		  struct cleanup *old_chain1 = NULL;
 
 		  aexpr = gen_trace_for_return_address (tloc->address,
-							t->gdbarch);
+							tloc->gdbarch);
 
 		  old_chain1 = make_cleanup_free_agent_expr (aexpr);
 
@@ -1403,7 +1403,7 @@ encode_actions_1 (struct command_line *action,
 		      {
 			const char *name = &exp->elts[2].string;
 
-			i = user_reg_map_name_to_regnum (t->gdbarch,
+			i = user_reg_map_name_to_regnum (tloc->gdbarch,
 							 name, strlen (name));
 			if (i == -1)
 			  internal_error (__FILE__, __LINE__,
@@ -1426,7 +1426,7 @@ encode_actions_1 (struct command_line *action,
 		    case OP_VAR_VALUE:
 		      collect_symbol (collect,
 				      exp->elts[2].symbol,
-				      t->gdbarch,
+				      tloc->gdbarch,
 				      frame_reg,
 				      frame_offset,
 				      tloc->address);
@@ -1539,8 +1539,8 @@ encode_actions (struct breakpoint *t, struct bp_location *tloc,
   *tdp_actions = NULL;
   *stepping_actions = NULL;
 
-  gdbarch_virtual_frame_pointer (t->gdbarch,
-				 t->loc->address, &frame_reg, &frame_offset);
+  gdbarch_virtual_frame_pointer (tloc->gdbarch,
+				 tloc->address, &frame_reg, &frame_offset);
 
   actions = breakpoint_commands (t);
 
-- 
1.7.6.4

Re: RFC: remove gdbarch from struct breakpoint

[Joel Brobecker]

> This patch removes the 'gdbarch' field from struct breakpoint.
> 
> In most cases, it is sufficient to replace the use of this field with
> the location's gdbarch instead.  In fact, I think the cases in
> tracepoint.c where this is not done are probably latent bugs.

I think that makes sense. I am trying to figure out how a breakpoint
could have a gdbarch that made some sort of sense when the breakpoint
has two locations and each location had a different gdbarch from
the other....

-- 
Joel

Re: RFC: remove gdbarch from struct breakpoint

[Pedro Alves]

On Monday 07 November 2011 15:20:58, Joel Brobecker wrote:
> > This patch removes the 'gdbarch' field from struct breakpoint.
> > 
> > In most cases, it is sufficient to replace the use of this field with
> > the location's gdbarch instead.  In fact, I think the cases in
> > tracepoint.c where this is not done are probably latent bugs.
> 
> I think that makes sense. I am trying to figure out how a breakpoint
> could have a gdbarch that made some sort of sense when the breakpoint
> has two locations and each location had a different gdbarch from
> the other....

History behind the fields:
 http://sourceware.org/ml/gdb-patches/2009-06/msg00215.html
and:
 http://sourceware.org/ml/gdb-patches/2009-07/msg00075.html

Reading the first url, I was wondering if we'd indeed need the
breakpoint's gdbarch for reparsing conditions and watchpoint
expressions (or anything that uses expressions instead of linespecs),
but I can't find such dependency in the code.  Maybe Ulrich can
take a look at this.  The Cell combined debugger can maybe
reveal hidden dependencies with the gdbarch fallbacks we do.

> In most cases, it is sufficient to replace the use of this field with
> the location's gdbarch instead.  In fact, I think the cases in
> tracepoint.c where this is not done are probably latent bugs.

Yeah.

-- 
Pedro Alves

Re: RFC: remove gdbarch from struct breakpoint

[Stan Shebs]

On 11/7/11 8:09 AM, Pedro Alves wrote:
> On Monday 07 November 2011 15:20:58, Joel Brobecker wrote:
>>> This patch removes the 'gdbarch' field from struct breakpoint.
>>>
>>> In most cases, it is sufficient to replace the use of this field with
>>> the location's gdbarch instead.  In fact, I think the cases in
>>> tracepoint.c where this is not done are probably latent bugs.
>> I think that makes sense. I am trying to figure out how a breakpoint
>> could have a gdbarch that made some sort of sense when the breakpoint
>> has two locations and each location had a different gdbarch from
>> the other....
> History behind the fields:
>   http://sourceware.org/ml/gdb-patches/2009-06/msg00215.html
> and:
>   http://sourceware.org/ml/gdb-patches/2009-07/msg00075.html
>
> Reading the first url, I was wondering if we'd indeed need the
> breakpoint's gdbarch for reparsing conditions and watchpoint
> expressions (or anything that uses expressions instead of linespecs),
> but I can't find such dependency in the code.  Maybe Ulrich can
> take a look at this.  The Cell combined debugger can maybe
> reveal hidden dependencies with the gdbarch fallbacks we do.
>

   break foo if sizeof($pc)==8  ?

Or one could conceivably have

   watch shared_mem_struct.afield

with different offsets and sizes for each arch accessing the field, but 
in practice the program's code is unlikely to work if they are 
different.  (Of course, it would be better for GDB to expose such an 
inconsistency, rather than silently using only the first gdbarch's 
version...)

Stan
stan@codesourcery.com

Re: RFC: remove gdbarch from struct breakpoint

[Ulrich Weigand]

Pedro Alves wrote:
> On Monday 07 November 2011 15:20:58, Joel Brobecker wrote:
> > I think that makes sense. I am trying to figure out how a breakpoint
> > could have a gdbarch that made some sort of sense when the breakpoint
> > has two locations and each location had a different gdbarch from
> > the other....
> 
> History behind the fields:
>  http://sourceware.org/ml/gdb-patches/2009-06/msg00215.html
> and:
>  http://sourceware.org/ml/gdb-patches/2009-07/msg00075.html
> 
> Reading the first url, I was wondering if we'd indeed need the
> breakpoint's gdbarch for reparsing conditions and watchpoint
> expressions (or anything that uses expressions instead of linespecs),
> but I can't find such dependency in the code.  Maybe Ulrich can
> take a look at this.  The Cell combined debugger can maybe
> reveal hidden dependencies with the gdbarch fallbacks we do.

Ahh.  That seems to be one of the "open ends" of multi-arch support
that has never been addressed so far.  Currently, expression parsing
always takes place in the "current" architecture context; see the
get_current_arch call in parse_exp_in_context.  This is really a bug;
the parse routines probably ought to take a gdbarch parameter instead.

(The reasons why expression parsing is dependent on the architecture
are basically those Stan described; things like how to interpret register
names, struct layout ABI, and predefined types like "long".)

Having a gdbarch field in "struct breakpoint" was in part a preparation
for this: once expression parsing is -properly- done specifically in an
architecture context, we need to decide which arch to pass when parsing
(and re-parsing) breakpoint conditions and expressions.  My thought was
that the right way to do that would be to remember and re-use the
architecture that was current at the time the expression was initially
entered; just like is currently done with the language and input radix
used when reparsing conditions and watchpoint expressions.

Most other architecture-dependent things in breakpoint.c etc really
should use a per-location architecture.  However, the way the per-
location arch is currently chosen is to either determine it from
the location --but this works only if we find a symtab!-- or else
fall back to the main breakpoint architecture.  If we remove that
fall back, there will be cases where breakpoints are set at locations
with no symtab (e.g. in generated code, stack trampolines, etc.)
and we will not find any associated architecture.

Now maybe it is not really correct to use the same field both for the
architecture to parse a breakpoint expression, and as the fall-back
location arch for locations without symtab.  Maybe the fall-back could
instead be a per-program_space default gdbarch ... or we could add a
gdbarch field to the SAL, and require all users to fill it ...

> > In most cases, it is sufficient to replace the use of this field with
> > the location's gdbarch instead.  In fact, I think the cases in
> > tracepoint.c where this is not done are probably latent bugs.
> 
> Yeah.

Agreed about the tracepoint.c uses.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: RFC: remove gdbarch from struct breakpoint

[Tom Tromey]

>>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:

Ulrich> Most other architecture-dependent things in breakpoint.c etc really
Ulrich> should use a per-location architecture.  However, the way the per-
Ulrich> location arch is currently chosen is to either determine it from
Ulrich> the location --but this works only if we find a symtab!-- or else
Ulrich> fall back to the main breakpoint architecture.  If we remove that
Ulrich> fall back, there will be cases where breakpoints are set at locations
Ulrich> with no symtab (e.g. in generated code, stack trampolines, etc.)
Ulrich> and we will not find any associated architecture.

Ok, I see.

Why not just use the location's arch when parsing and re-parsing the
expression, though?  With my patches this still defaults to the current
arch when the breakpoint is set -- this just isn't stored on the
breakpoint any more.  (Now get_sal_arch tries to get the objfile arch as
a fallback, which I hope avoids any missing cases.)

Tom

Re: RFC: remove gdbarch from struct breakpoint

[Ulrich Weigand]

Tom Tromey wrote:
> >>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:
> 
> Ulrich> Most other architecture-dependent things in breakpoint.c etc really
> Ulrich> should use a per-location architecture.  However, the way the per-
> Ulrich> location arch is currently chosen is to either determine it from
> Ulrich> the location --but this works only if we find a symtab!-- or else
> Ulrich> fall back to the main breakpoint architecture.  If we remove that
> Ulrich> fall back, there will be cases where breakpoints are set at locations
> Ulrich> with no symtab (e.g. in generated code, stack trampolines, etc.)
> Ulrich> and we will not find any associated architecture.
> 
> Ok, I see.
> 
> Why not just use the location's arch when parsing and re-parsing the
> expression, though?

Well, which location?  A single breakpoint might expand to multiple
locations in different architectures, any or none of which might
be the same as the current architecture at the time the breakpoint
is initially entered ...

For example, today we could add a breakpoint like:
  break spu.c:123 if var.offset == 123
while currently in PowerPC architecture.  The way this was intended
to work is to set a breakpoint location on spu.c:123 (with a location
architecture of "spu"), while evaluating the condition using
PowerPC architecture settings.

> With my patches this still defaults to the current
> arch when the breakpoint is set -- this just isn't stored on the
> breakpoint any more.

Actually, it doesn't: the location arch is retrieved from the SAL,
it only falls back to the current arch if there is no architecture
associated with the SAL.  So in the case mentioned above, the
location arch would be set to "spu", and the fact that the current
arch was "powerpc" when the breakpoint was set would be lost.

> (Now get_sal_arch tries to get the objfile arch as
> a fallback, which I hope avoids any missing cases.)

Well, in the cases I mentioned above (generated code, stack trampolines)
-- which are rare, but possible, breakpoint targets, especially for
single-step breakpoints -- there is no objfile either.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: RFC: remove gdbarch from struct breakpoint

[Tom Tromey]

>>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:

Ulrich> For example, today we could add a breakpoint like:
Ulrich>   break spu.c:123 if var.offset == 123
Ulrich> while currently in PowerPC architecture.  The way this was intended
Ulrich> to work is to set a breakpoint location on spu.c:123 (with a location
Ulrich> architecture of "spu"), while evaluating the condition using
Ulrich> PowerPC architecture settings.

Ok.

Ulrich> Well, in the cases I mentioned above (generated code, stack trampolines)
Ulrich> -- which are rare, but possible, breakpoint targets, especially for
Ulrich> single-step breakpoints -- there is no objfile either.

Yeah, I understand now.

Looking back, I am not certain there is an actual need for this patch.
I am going to see what happens if I just drop it.

If I do drop it, I will still pull in the tracepoint changes, since I
think those are probably good.

Tom

Re: RFC: remove gdbarch from struct breakpoint

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> Looking back, I am not certain there is an actual need for this patch.
Tom> I am going to see what happens if I just drop it.

It all still seems to work.  I think I thought I needed that patch, so I
wrote it early on, but turned out to be mistaken about this and didn't
notice.

Tom

FYI: tracepoints and multi-arch (Was: RFC: remove gdbarch from struct breakpoint)

[Tom Tromey]

Tom> If I do drop it, I will still pull in the tracepoint changes, since I
Tom> think those are probably good.

I am checking this in, as discussed.

This patch fixes a few spots where tracepoints rely on the breakpoint's
arch; in general I think the location's arch is more appropriate.

Tom

2011-11-14  Tom Tromey  <tromey@redhat.com>

	* tracepoint.c (encode_actions_1): Use the location's gdbarch.
	(encode_actions): Likewise.

Index: tracepoint.c
===================================================================
RCS file: /cvs/src/src/gdb/tracepoint.c,v
retrieving revision 1.236
diff -u -r1.236 tracepoint.c
--- tracepoint.c	14 Nov 2011 15:18:54 -0000	1.236
+++ tracepoint.c	14 Nov 2011 16:07:57 -0000
@@ -1370,14 +1370,14 @@
 
 	      if (0 == strncasecmp ("$reg", action_exp, 4))
 		{
-		  for (i = 0; i < gdbarch_num_regs (t->gdbarch); i++)
+		  for (i = 0; i < gdbarch_num_regs (tloc->gdbarch); i++)
 		    add_register (collect, i);
 		  action_exp = strchr (action_exp, ',');	/* more? */
 		}
 	      else if (0 == strncasecmp ("$arg", action_exp, 4))
 		{
 		  add_local_symbols (collect,
-				     t->gdbarch,
+				     tloc->gdbarch,
 				     tloc->address,
 				     frame_reg,
 				     frame_offset,
@@ -1387,7 +1387,7 @@
 	      else if (0 == strncasecmp ("$loc", action_exp, 4))
 		{
 		  add_local_symbols (collect,
-				     t->gdbarch,
+				     tloc->gdbarch,
 				     tloc->address,
 				     frame_reg,
 				     frame_offset,
@@ -1399,7 +1399,7 @@
 		  struct cleanup *old_chain1 = NULL;
 
 		  aexpr = gen_trace_for_return_address (tloc->address,
-							t->gdbarch);
+							tloc->gdbarch);
 
 		  old_chain1 = make_cleanup_free_agent_expr (aexpr);
 
@@ -1452,7 +1452,7 @@
 		      {
 			const char *name = &exp->elts[2].string;
 
-			i = user_reg_map_name_to_regnum (t->gdbarch,
+			i = user_reg_map_name_to_regnum (tloc->gdbarch,
 							 name, strlen (name));
 			if (i == -1)
 			  internal_error (__FILE__, __LINE__,
@@ -1475,7 +1475,7 @@
 		    case OP_VAR_VALUE:
 		      collect_symbol (collect,
 				      exp->elts[2].symbol,
-				      t->gdbarch,
+				      tloc->gdbarch,
 				      frame_reg,
 				      frame_offset,
 				      tloc->address);
@@ -1588,8 +1588,8 @@
   *tdp_actions = NULL;
   *stepping_actions = NULL;
 
-  gdbarch_virtual_frame_pointer (t->gdbarch,
-				 t->loc->address, &frame_reg, &frame_offset);
+  gdbarch_virtual_frame_pointer (tloc->gdbarch,
+				 tloc->address, &frame_reg, &frame_offset);
 
   actions = breakpoint_commands (t);