This is the mail archive of the gdb-prs@sources.redhat.com 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]

pending/1527: Overlay target stratum?


>Number:         1527
>Category:       pending
>Synopsis:       Overlay target stratum?
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   unknown
>Arrival-Date:   Mon Jan 19 20:18:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 Hello,
 
 In working through target code, I keep comming across overlay stuff. 
 I'm wondering if it should be moved to its own overlay-target stratum?
 
 The user could then (at least in theory) view memory according to the 
 overlay, or according to the underlying physical representation.  Also, 
 totally in theory, a variant of the stratum could be implemented that 
 modeled an OS's VM system!  However, that's a later bridge to cross.
 
 The approach would be:
 
 	target has segments (aka section_table)
 
 	segment has
 		base, length
 		offset
 		target (or bfd)
 
 A memory read/write would do a virtual/physical translation using the 
 segment (aka section table) and then call the underlying target's xfer 
 function.
 
 Actual code would be:
 
 	s = this->section_by_addr (addr);
 	s->target->xfer (addr - s->base + s->offset, len adjusted by s->length
 
 The existing code already does this, but only for bfd backed segments.
 (Oh, the existing code also does really evil things with the section 
 table - independant targets somehow sharing a common table :-()
 
 
 Thoughts?
 
 thoughts?
 Andrew
 
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:


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