* [rfa:ppc64] Use target in convert_from_func_ptr_addr
@ 2003-10-23 1:37 Andrew Cagney
2003-10-23 16:00 ` Kevin Buettner
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2003-10-23 1:37 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 237 bytes --]
Hello,
The attached rewrites the PPC64 GNU/Linux convert_from_func_ptr_addr
method so that it makes use of the explicit "struct target_ops"
parameter I recently added (previously it was indirectly using
current_target).
ok?
Andrew
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1116 bytes --]
2003-10-17 Andrew Cagney <cagney@redhat.com>
* ppc-linux-tdep.c (ppc64_linux_convert_from_func_ptr_addr):
Rewrite to use target_ops when transfering memory.
Index: ppc-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ppc-linux-tdep.c,v
retrieving revision 1.44
diff -u -r1.44 ppc-linux-tdep.c
--- ppc-linux-tdep.c 22 Oct 2003 23:54:11 -0000 1.44
+++ ppc-linux-tdep.c 23 Oct 2003 01:32:51 -0000
@@ -936,14 +936,14 @@
CORE_ADDR addr,
struct target_ops *targ)
{
- struct obj_section *s;
-
- s = find_pc_section (addr);
-
- /* Check if ADDR points to a function descriptor. */
- if (s && strcmp (s->the_bfd_section->name, ".opd") == 0)
- return read_memory_unsigned_integer (addr, 8);
-
+ struct section_table *s = target_section_by_addr (targ, addr);
+ if (s != NULL && s->the_bfd_section != NULL
+ && strcmp (s->the_bfd_section->name, ".opd") == 0)
+ {
+ char desc[8];
+ target_read (targ, TARGET_OBJECT_MEMORY, NULL, desc, addr, 8);
+ return extract_unsigned_integer (desc, 8);
+ }
return addr;
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [rfa:ppc64] Use target in convert_from_func_ptr_addr
2003-10-23 1:37 [rfa:ppc64] Use target in convert_from_func_ptr_addr Andrew Cagney
@ 2003-10-23 16:00 ` Kevin Buettner
2003-10-23 16:26 ` Andrew Cagney
0 siblings, 1 reply; 8+ messages in thread
From: Kevin Buettner @ 2003-10-23 16:00 UTC (permalink / raw)
To: Andrew Cagney, gdb-patches
On Oct 22, 9:37pm, Andrew Cagney wrote:
> The attached rewrites the PPC64 GNU/Linux convert_from_func_ptr_addr
> method so that it makes use of the explicit "struct target_ops"
> parameter I recently added (previously it was indirectly using
> current_target).
[...]
> Index: ppc-linux-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/ppc-linux-tdep.c,v
> retrieving revision 1.44
> diff -u -r1.44 ppc-linux-tdep.c
> --- ppc-linux-tdep.c 22 Oct 2003 23:54:11 -0000 1.44
> +++ ppc-linux-tdep.c 23 Oct 2003 01:32:51 -0000
> @@ -936,14 +936,14 @@
> CORE_ADDR addr,
> struct target_ops *targ)
> {
> - struct obj_section *s;
> -
> - s = find_pc_section (addr);
> -
> - /* Check if ADDR points to a function descriptor. */
> - if (s && strcmp (s->the_bfd_section->name, ".opd") == 0)
> - return read_memory_unsigned_integer (addr, 8);
> -
> + struct section_table *s = target_section_by_addr (targ, addr);
> + if (s != NULL && s->the_bfd_section != NULL
> + && strcmp (s->the_bfd_section->name, ".opd") == 0)
> + {
> + char desc[8];
> + target_read (targ, TARGET_OBJECT_MEMORY, NULL, desc, addr, 8);
> + return extract_unsigned_integer (desc, 8);
> + }
> return addr;
> }
IMO, this version of the code is harder to read than the old version.
Can you explain what using an explicit `struct target_ops'' parameter
buys us?
Kevin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [rfa:ppc64] Use target in convert_from_func_ptr_addr
2003-10-23 16:00 ` Kevin Buettner
@ 2003-10-23 16:26 ` Andrew Cagney
2003-10-23 17:12 ` Kevin Buettner
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2003-10-23 16:26 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
> On Oct 22, 9:37pm, Andrew Cagney wrote:
>
>
>> The attached rewrites the PPC64 GNU/Linux convert_from_func_ptr_addr
>> method so that it makes use of the explicit "struct target_ops"
>> parameter I recently added (previously it was indirectly using
>> current_target).
>
> IMO, this version of the code is harder to read than the old version.
>
> Can you explain what using an explicit `struct target_ops'' parameter
> buys us?
By using the explicit "struct target_ops", I've eliminated the
assumption that the _single_ _global_ current_target contains the
function descriptor.
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [rfa:ppc64] Use target in convert_from_func_ptr_addr
2003-10-23 16:26 ` Andrew Cagney
@ 2003-10-23 17:12 ` Kevin Buettner
2003-10-23 21:02 ` Andrew Cagney
0 siblings, 1 reply; 8+ messages in thread
From: Kevin Buettner @ 2003-10-23 17:12 UTC (permalink / raw)
To: Andrew Cagney, Kevin Buettner; +Cc: gdb-patches
On Oct 23, 12:26pm, Andrew Cagney wrote:
> > On Oct 22, 9:37pm, Andrew Cagney wrote:
> >
> >
> >> The attached rewrites the PPC64 GNU/Linux convert_from_func_ptr_addr
> >> method so that it makes use of the explicit "struct target_ops"
> >> parameter I recently added (previously it was indirectly using
> >> current_target).
>
> >
> > IMO, this version of the code is harder to read than the old version.
> >
> > Can you explain what using an explicit `struct target_ops'' parameter
> > buys us?
>
> By using the explicit "struct target_ops", I've eliminated the
> assumption that the _single_ _global_ current_target contains the
> function descriptor.
Yes. But what does this buy us? I.e, what will we be able to do after
this patch that we couldn't do before?
Kevin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [rfa:ppc64] Use target in convert_from_func_ptr_addr
2003-10-23 17:12 ` Kevin Buettner
@ 2003-10-23 21:02 ` Andrew Cagney
2003-10-23 21:23 ` Kevin Buettner
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2003-10-23 21:02 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
> On Oct 23, 12:26pm, Andrew Cagney wrote:
>
>
>> > On Oct 22, 9:37pm, Andrew Cagney wrote:
>> >
>> >
>
>> >> The attached rewrites the PPC64 GNU/Linux convert_from_func_ptr_addr
>> >> method so that it makes use of the explicit "struct target_ops"
>> >> parameter I recently added (previously it was indirectly using
>> >> current_target).
>
>>
>
>> >
>> > IMO, this version of the code is harder to read than the old version.
If you want I can add a wrapper method, reducing the actual change to
just the modification of:
- return read_memory_unsigned_integer (addr, 8);
to:
+ return get_target_memory_unsigned (targ, addr, 8);
>> > Can you explain what using an explicit `struct target_ops'' parameter
>> > buys us?
>
>>
>> By using the explicit "struct target_ops", I've eliminated the
>> assumption that the _single_ _global_ current_target contains the
>> function descriptor.
>
>
> Yes. But what does this buy us? I.e, what will we be able to do after
> this patch that we couldn't do before?
The ability to apply this architecture method to an arbitrary target
instance? Sorry, but I'm afraid that I'm missing something in your
question.
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [rfa:ppc64] Use target in convert_from_func_ptr_addr
2003-10-23 21:02 ` Andrew Cagney
@ 2003-10-23 21:23 ` Kevin Buettner
2003-10-23 22:31 ` Andrew Cagney
2003-10-24 20:27 ` [commit] Add get_target_memory ... + " Andrew Cagney
0 siblings, 2 replies; 8+ messages in thread
From: Kevin Buettner @ 2003-10-23 21:23 UTC (permalink / raw)
To: Andrew Cagney, Kevin Buettner; +Cc: gdb-patches
On Oct 23, 5:02pm, Andrew Cagney wrote:
> If you want I can add a wrapper method, reducing the actual change to
> just the modification of:
>
> - return read_memory_unsigned_integer (addr, 8);
>
> to:
>
> + return get_target_memory_unsigned (targ, addr, 8);
That'd be great. (With this change, consider it approved.)
> > Yes. But what does this buy us? I.e, what will we be able to do after
> > this patch that we couldn't do before?
>
> The ability to apply this architecture method to an arbitrary target
> instance? Sorry, but I'm afraid that I'm missing something in your
> question.
I'm trying to understand where you're going with these changes. Do
you anticipate that this architecture method will ever be called
with anything other than current_target? If so, then under what
circumstances? Will a GDB user see enhanced functionality as a
result?
Kevin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [rfa:ppc64] Use target in convert_from_func_ptr_addr
2003-10-23 21:23 ` Kevin Buettner
@ 2003-10-23 22:31 ` Andrew Cagney
2003-10-24 20:27 ` [commit] Add get_target_memory ... + " Andrew Cagney
1 sibling, 0 replies; 8+ messages in thread
From: Andrew Cagney @ 2003-10-23 22:31 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
> I'm trying to understand where you're going with these changes.
See my most recent posts to gdb@, along with the archives. There is a
long standing and oft repeated goal of cleaning up the target stack. In
part making it more OO.
> Will a GDB user see enhanced functionality as a
> result?
I guess so. At present FSF's GDB when debugging shared libraries on
GNU/Linux does this:
(top-gdb) run
Starting program:
/home/cagney/PENDING/YYYY-MM-DD-target-convert-func/64/gdb/gdb
Warning:
Cannot insert breakpoint -1.
Error accessing memory address 0x7fdffec35c: Input/output error.
(top-gdb)
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* [commit] Add get_target_memory ... + Use target in convert_from_func_ptr_addr
2003-10-23 21:23 ` Kevin Buettner
2003-10-23 22:31 ` Andrew Cagney
@ 2003-10-24 20:27 ` Andrew Cagney
1 sibling, 0 replies; 8+ messages in thread
From: Andrew Cagney @ 2003-10-24 20:27 UTC (permalink / raw)
To: Kevin Buettner, gdb-patches
[-- Attachment #1: Type: text/plain, Size: 568 bytes --]
> On Oct 23, 5:02pm, Andrew Cagney wrote:
>
>
>> If you want I can add a wrapper method, reducing the actual change to
>> just the modification of:
>>
>> - return read_memory_unsigned_integer (addr, 8);
>>
>> to:
>>
>> + return get_target_memory_unsigned (targ, addr, 8);
>
>
> That'd be great. (With this change, consider it approved.)
I've committed the attached. It also adds the new target wrapper methods:
get_target_memory
and
get_target_memory_unsigned
(I'm wondering about putting them in a separate file, but that's
separate ...)
Andrew
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3944 bytes --]
2003-10-24 Andrew Cagney <cagney@redhat.com>
* target.c: Include "gdbcore.h".
(get_target_memory, get_target_memory_unsigned): New functions.
* target.h (get_target_memory, get_target_memory_unsigned): Declare.
* ppc-linux-tdep.c (ppc64_linux_convert_from_func_ptr_addr):
Use get_target_memory_unsigned.
* Makefile.in (target.o): Update dependencies.
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.462
diff -u -r1.462 Makefile.in
--- Makefile.in 23 Oct 2003 22:36:14 -0000 1.462
+++ Makefile.in 24 Oct 2003 20:21:53 -0000
@@ -2367,7 +2367,8 @@
$(block_h) $(dictionary_h) $(gdb_string_h) $(gdb_stat_h) $(cp_abi_h)
target.o: target.c $(defs_h) $(gdb_string_h) $(target_h) $(gdbcmd_h) \
$(symtab_h) $(inferior_h) $(bfd_h) $(symfile_h) $(objfiles_h) \
- $(gdb_wait_h) $(dcache_h) $(regcache_h) $(gdb_assert_h)
+ $(gdb_wait_h) $(dcache_h) $(regcache_h) $(gdb_assert_h) \
+ $(gdbcore_h)
thread.o: thread.c $(defs_h) $(symtab_h) $(frame_h) $(inferior_h) \
$(environ_h) $(value_h) $(target_h) $(gdbthread_h) $(command_h) \
$(gdbcmd_h) $(regcache_h) $(gdb_h) $(gdb_string_h) $(ui_out_h)
Index: ppc-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ppc-linux-tdep.c,v
retrieving revision 1.44
diff -u -r1.44 ppc-linux-tdep.c
--- ppc-linux-tdep.c 22 Oct 2003 23:54:11 -0000 1.44
+++ ppc-linux-tdep.c 24 Oct 2003 20:21:54 -0000
@@ -936,13 +936,11 @@
CORE_ADDR addr,
struct target_ops *targ)
{
- struct obj_section *s;
-
- s = find_pc_section (addr);
+ struct section_table *s = target_section_by_addr (targ, addr);
/* Check if ADDR points to a function descriptor. */
if (s && strcmp (s->the_bfd_section->name, ".opd") == 0)
- return read_memory_unsigned_integer (addr, 8);
+ return get_target_memory_unsigned (targ, addr, 8);
return addr;
}
Index: target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.62
diff -u -r1.62 target.c
--- target.c 23 Oct 2003 00:13:53 -0000 1.62
+++ target.c 24 Oct 2003 20:21:54 -0000
@@ -37,6 +37,7 @@
#include <signal.h>
#include "regcache.h"
#include "gdb_assert.h"
+#include "gdbcore.h"
static void target_info (char *, int);
@@ -1212,6 +1213,28 @@
QUIT;
}
return len;
+}
+
+/* Memory transfer methods. */
+
+void
+get_target_memory (struct target_ops *ops, CORE_ADDR addr, void *buf,
+ LONGEST len)
+{
+ if (target_read (ops, TARGET_OBJECT_MEMORY, NULL, buf, addr, len)
+ != len)
+ memory_error (EIO, addr);
+}
+
+ULONGEST
+get_target_memory_unsigned (struct target_ops *ops,
+ CORE_ADDR addr, int len)
+{
+ char buf[sizeof (ULONGEST)];
+
+ gdb_assert (len <= sizeof (buf));
+ get_target_memory (ops, addr, buf, len);
+ return extract_unsigned_integer (buf, len);
}
static void
Index: target.h
===================================================================
RCS file: /cvs/src/src/gdb/target.h,v
retrieving revision 1.48
diff -u -r1.48 target.h
--- target.h 23 Oct 2003 03:01:55 -0000 1.48
+++ target.h 24 Oct 2003 20:21:54 -0000
@@ -248,6 +248,18 @@
enum target_object object,
const char *annex, const void *buf,
ULONGEST offset, LONGEST len);
+
+/* Wrappers to target read/write that perform memory transfers. They
+ throw an error if the memory transfer fails.
+
+ NOTE: cagney/2003-10-23: The naming schema is lifted from
+ "frame.h". The parameter order is lifted from get_frame_memory,
+ which in turn lifted it from read_memory. */
+
+extern void get_target_memory (struct target_ops *ops, CORE_ADDR addr,
+ void *buf, LONGEST len);
+extern ULONGEST get_target_memory_unsigned (struct target_ops *ops,
+ CORE_ADDR addr, int len);
\f
/* If certain kinds of activity happen, target_wait should perform
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-10-24 20:27 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-23 1:37 [rfa:ppc64] Use target in convert_from_func_ptr_addr Andrew Cagney
2003-10-23 16:00 ` Kevin Buettner
2003-10-23 16:26 ` Andrew Cagney
2003-10-23 17:12 ` Kevin Buettner
2003-10-23 21:02 ` Andrew Cagney
2003-10-23 21:23 ` Kevin Buettner
2003-10-23 22:31 ` Andrew Cagney
2003-10-24 20:27 ` [commit] Add get_target_memory ... + " Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox