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" >>To: "GDB Patches" >>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?