[wip] BFD from an arbitrary object; Was: provide pass-through value in bfd_elf_bfd_from_remote_memory

[Andrew Cagney]

Hello,

> Hi Jim,
> 
> 
>> Nick, I didn't see anything from you on the following patch:
>>
>> http://sources.redhat.com/ml/binutils/2003-05/msg00658.html
>>
>> It's a patch to bfd_elf_bfd_from_remote_memory, which was written by
>> Roland McGrath; Roland says it's fine with him.
> 
> 
> Right, but there was quite a Long discussion between you and Andrew
> about several points and I thought that you were going to submit a
> revised patch ??

Picking up an old thread.

The attached work-in-progress (GDB works) adds a "struct bfd_file" 
object to bfd/.  It then modifies the "struct bfd" so that an instance 
of a "bfd_file" is used for I/O.

By doing this it becomes possible to:

- cleanup the existing code
Replacing this:
	if (bfd & BFD_IN_MEMORY)
	  do memory I/O op
	else
	  do file I/O
with this:
	bfd->stream->I/O op (bfd)
along with separate bfd-in-memory and "cache" "struct bfd_file"s.

- let clients implement arbitrary files
In particular, and immediatly, a stream that is backed by the memory 
found in the inferior that GDB is debugging.

My immediate interest is in opinion (in particular from Nick and Alan) 
on questions such as:

- is the theory ok?

- given there are N equally effective ways of implementing the "struct 
bfd_file" object, is the attached reasonable?

- what to do about mmap?
I ignored it as it isn't enabled by default :-/  I personally think that 
it should be let be until this is in and then BFD and GDB figure out how 
exactly they both want mmap to work.

- do the changes to cache.c scare anyone (I've not checked them 
carefully yet :-)?

The other question is of course (and assuming the theory is ok) how 
should this be integrated?

Andrew

PS: Yes, I know, I "lost" the bfd-in-memory code.  I intend moving it to 
the new file "bim.c".
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
URL: <https://sourceware.org/pipermail/binutils/attachments/20040214/f10ba126/attachment.ksh>