From: Michael Snyder <msnyder@redhat.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: GDB Patches <gdb-patches@sources.redhat.com>
Subject: Re: [rfa] Restore "trust-readonly-section"
Date: Tue, 24 May 2005 02:03:00 -0000 [thread overview]
Message-ID: <42927D75.4050009@redhat.com> (raw)
In-Reply-To: <20050515171254.GC11855@nevyn.them.org>
[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]
Daniel Jacobowitz wrote:
> On Thu, May 12, 2005 at 04:14:19PM -0700, Michael Snyder wrote:
>
>>Hmm, tabs fubar -- I'll try again with the patch as an attachment.
>>
>>----- Original Message -----
>>From: "Michael Snyder" <msnyder@redhat.com>
>>To: "GDB Patches" <gdb-patches@sources.redhat.com>
>>Sent: Thursday, May 12, 2005 3:55 PM
>>Subject: [rfa] Restore "trust-readonly-section"
>>
>>
>>
>>>This seems to have succumbed to bit-rot -- there are new target-read
>>>functions
>>>in target.c that don't pay any attention to this user-settable mode bit.
>>>
>>>The purpose of "trust-readonly-sections" is to improve speed on
>>>targets where reading memory is expensive (mostly remote).
>>>It checks to see if a read is from a read-only section, and if so,
>>>reads it from the exec file. It defaults to "off" for safety, but if
>>>users choose to use it, it really speeds up prologue analysis
>>>(and therefore stepping).
>>>
>>>This patch just makes it work again.
>
>
> It seems odd to add the test both in target_xfer_partial (a dispatcher)
> and default_xfer_partial (an implementation). Are they really both
> necessary?
I suppose you're right -- but I'm bewildered by the number of
possible entry points and paths thru this code. In theory
I think I could get away with just covering three points:
target_read_memory, target_read_partial, and target_read_memory_partial,
were it not for the fact that do_xfer_memory is also an entry point.
do_xfer_memory seems to only be called from dcache.c --
but it's extern, so nothing prevents others from calling it.
And dcache_xfer_memory is extern too, so one can get in thru there
(although again, no one currently does AFAICT).
> The code might be simpler if you push the trust_readonly check inside
> target_read_trusted. Also, could you name that something involving
> memory?
OK -- how about the attached, which includes four entry points?
[-- Attachment #2: trust-readonly --]
[-- Type: text/plain, Size: 5641 bytes --]
2005-05-12 Michael Snyder <msnyder@redhat.com>
* target.c (target_read_memory_trusted): New function.
Implements "trust-readonly-section".
(target_read_partial): Honor trust-readonly-section.
(target_read_memory_partial): Ditto.
(target_read_memory): Ditto.
(do_xfer_memory): Ditto.
Index: target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.108
diff -p -r1.108 target.c
*** target.c 16 May 2005 16:36:24 -0000 1.108
--- target.c 24 May 2005 01:00:20 -0000
*************** target_section_by_addr (struct target_op
*** 845,850 ****
--- 845,884 ----
return NULL;
}
+ static int trust_readonly = 0;
+ static void
+ show_trust_readonly (struct ui_file *file, int from_tty,
+ struct cmd_list_element *c, const char *value)
+ {
+ fprintf_filtered (file,
+ _("Mode for reading from readonly sections is %s.\n"),
+ value);
+ }
+
+ /* If trust-readonly-sections, and if MEMADDR is within a
+ read-only section, read LEN bytes from the bfd at MEMADDR,
+ placing the results in GDB's memory at MYADDR. Returns
+ the number of bytes read. */
+
+ static int
+ target_read_memory_trusted (CORE_ADDR memaddr, char *myaddr, int len)
+ {
+ struct section_table *secp;
+ /* User-settable option, "trust-readonly-sections". If true,
+ then memory from any SEC_READONLY bfd section may be read
+ directly from the bfd file. */
+ if (trust_readonly)
+ {
+ secp = target_section_by_addr (¤t_target, memaddr);
+ if (secp != NULL
+ && (bfd_get_section_flags (secp->bfd, secp->the_bfd_section)
+ & SEC_READONLY))
+ return xfer_memory (memaddr, myaddr, len, 0, NULL, ¤t_target);
+ }
+
+ return 0;
+ }
+
/* Return non-zero when the target vector has supplied an xfer_partial
method and it, rather than xfer_memory, should be used. */
static int
*************** xfer_using_stratum (enum target_object o
*** 999,1004 ****
--- 1033,1044 ----
int
target_read_memory (CORE_ADDR memaddr, gdb_byte *myaddr, int len)
{
+ int ret;
+
+ /* Honor "trust-readonly-sections" if set. */
+ if ((ret = target_read_memory_trusted (memaddr, myaddr, len)) > 0)
+ return (ret != len);
+
if (target_xfer_partial_p ())
return xfer_using_stratum (TARGET_OBJECT_MEMORY, NULL,
memaddr, len, myaddr, NULL);
*************** target_stopped_data_address_p (struct ta
*** 1033,1048 ****
}
#endif
- static int trust_readonly = 0;
- static void
- show_trust_readonly (struct ui_file *file, int from_tty,
- struct cmd_list_element *c, const char *value)
- {
- fprintf_filtered (file, _("\
- Mode for reading from readonly sections is %s.\n"),
- value);
- }
-
/* Move memory to or from the targets. The top target gets priority;
if it cannot handle it, it is offered to the next one down, etc.
--- 1073,1078 ----
*************** do_xfer_memory (CORE_ADDR memaddr, gdb_b
*** 1060,1082 ****
if (len == 0)
return 0;
/* deprecated_xfer_memory is not guaranteed to set errno, even when
it returns 0. */
errno = 0;
- if (!write && trust_readonly)
- {
- struct section_table *secp;
- /* User-settable option, "trust-readonly-sections". If true,
- then memory from any SEC_READONLY bfd section may be read
- directly from the bfd file. */
- secp = target_section_by_addr (¤t_target, memaddr);
- if (secp != NULL
- && (bfd_get_section_flags (secp->bfd, secp->the_bfd_section)
- & SEC_READONLY))
- return xfer_memory (memaddr, myaddr, len, 0, attrib, ¤t_target);
- }
-
/* The quick case is that the top target can handle the transfer. */
res = current_target.deprecated_xfer_memory
(memaddr, myaddr, len, write, attrib, ¤t_target);
--- 1090,1104 ----
if (len == 0)
return 0;
+ /* Honor "trust-readonly-sections" if set. */
+ if (!write &&
+ (res = target_read_memory_trusted (memaddr, myaddr, len)) > 0)
+ return res;
+
/* deprecated_xfer_memory is not guaranteed to set errno, even when
it returns 0. */
errno = 0;
/* The quick case is that the top target can handle the transfer. */
res = current_target.deprecated_xfer_memory
(memaddr, myaddr, len, write, attrib, ¤t_target);
*************** target_xfer_memory_partial (CORE_ADDR me
*** 1244,1253 ****
int
target_read_memory_partial (CORE_ADDR memaddr, char *buf, int len, int *err)
{
if (target_xfer_partial_p ())
{
- int retval;
-
retval = target_xfer_partial (target_stack, TARGET_OBJECT_MEMORY,
NULL, buf, NULL, memaddr, len);
--- 1266,1279 ----
int
target_read_memory_partial (CORE_ADDR memaddr, char *buf, int len, int *err)
{
+ int retval;
+
+ /* Honor "trust-readonly-sections" if set. */
+ if ((retval = target_read_memory_trusted (memaddr, buf, len)) > 0)
+ return retval;
+
if (target_xfer_partial_p ())
{
retval = target_xfer_partial (target_stack, TARGET_OBJECT_MEMORY,
NULL, buf, NULL, memaddr, len);
*************** target_read_partial (struct target_ops *
*** 1351,1356 ****
--- 1377,1389 ----
const char *annex, gdb_byte *buf,
ULONGEST offset, LONGEST len)
{
+ int ret;
+
+ /* Honor "trust-readonly-sections" if set. */
+ if (object == TARGET_OBJECT_MEMORY)
+ if ((ret = target_read_memory_trusted (offset, buf, len)) > 0)
+ return ret;
+
return target_xfer_partial (ops, object, annex, buf, NULL, offset, len);
}
next prev parent reply other threads:[~2005-05-24 1:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-13 6:29 Michael Snyder
2005-05-13 11:41 ` Michael Snyder
2005-05-15 17:25 ` Daniel Jacobowitz
2005-05-24 2:03 ` Michael Snyder [this message]
2005-05-28 22:55 ` Daniel Jacobowitz
2005-06-11 15:26 ` Mark Kettenis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42927D75.4050009@redhat.com \
--to=msnyder@redhat.com \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox