This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

More questions on memory read/write methods


Hi,
I've took a second look at code paths used to implement read and write for 
memory and special object, and have a number of questions.

Suppose we call target_write_memory, then the code will work like this:

    - if target_stack->to_xfer_partial == default_xfer_partial

        - target_xfer_memory is called

            (inside target_xfer_memory)

            - lookup_mem_region is called

            - memory request is clipped to the memory region size,
              region flags like "read-only" are checked.

            - Successive calls to do_xfer_memory are done until all memory
              is transferred.

                (inside do_xfer_memory)

                - an attempt is made to fulfill read request right from
                  object file (for write operation -- noop)
 
                - calls to target_ops->deprecated_xfer_memory are done, for
                  each target in target_stack

    - if target_stack->to_xfer_partial != default_xfer_partial

        - xfer_using_stratum is called

            (inside xfer_using_stratum)

            -  Walks over target_stack, calling target_xfer_partial

                (inside target_xfer_partial)
                
                - Direct call to target_ops->to_xfer_partial is done


Now the questions:

1. If target_stack->to_xfer_partial == default_xfer_partial, then we use 
deprecated_xfer_memory to do the memory transfer, we never call 
default_xfer_partial inside target_write_memory. Is that right?

2. If, yes, then default_xfer_partial can only be called from either 
target_read_partial, or target_write_partial, which are explicitly called by 
user, or by target_write/target_read with TARGET_OBJECT_MEMORY as parameter.

Is that's true, then why default_xfer_partial for the case where object == 
TARGET_OBJECT_MEMORY does not repeat the logic done by  target_xfer_memory?
It does no clipping of memory to memory regions, no checking of RO flags of 
memory, and does not iterate over target_stack. It just calls 
target_ops->deprecated_xfer_memory.

3. If target_stack->to_xfer_partial != default_xfer_partial, then a direct
call to it is made. Why the above-mentioned clipping to memory region is not 
performed in this case? Is the assumption that to_xfer_partial will do it? 
Then why the same assumption is not applied to deprecated_xfer_memory, and 
why this memory region clipping is done at all?

4. The do_xfer_memory will try to read data from binary file, if 
'trust_readonly' variable is set. This does not happens when 
target_stack->to_xfer_partial != default_xfer_partial. Why?

5. Would it be reasonable for xfer_using_stratum, when object == 
TARGET_OBJECT_MEMORY, to check to 'to_has_memory' and 'to_has_all_memory' 
fields?

6. Would it be reasonable for do_xfer_memory, instead of iterating over target 
stack itself, just call xfer_using_stratum?

Thanks in advance,
Volodya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]