Hi,

    I have updated the patch.

-Doug

2009-08-18  Doug Kwan  <dougkwan@google.com>

	* dynobj.cc (Sized_dynobj::setup): Take a Target object instead of
	an elcpp::Ehdr as parameter.  Adjust call to set_target.
	* dynobj.h (Sized_dynobj::setup): Take a Target object instead of
	an elfcpp::Ehdr as parameter.
	* object.cc (Object::set_target): Remove the version that looks up
	a target and sets it.
	(Sized_relobj::setup): Take a Target object instead of
	an elfcpp::Ehdr as parameter.  Adjust call to set_target.
	(make_elf_sized_object): Find target and ask target to
	make an ELF object.
	* object.h: (Object::set_target): Remove the version that looks up
	a target and sets it.
	(Sized_relobj::setup): Take a Target object instead of
	an elfcpp:Ehdr as parameter.
	* target.cc: Include dynobj.h.
	(Target::do_make_elf_object_implementation): New.
 	(Target::do_make_elf_object): New.
	* target.h (Target::make_elf_object): New template declaration.
	(Target::do_make_elf_object): New method declarations.
	(Target::do_make_elf_object_implementation): New template declaration.


2009/8/18 Ian Lance Taylor <iant@google.com>:
> "Doug Kwan (Ãö®¶¼w)" <dougkwan@google.com> writes:
>
>> 2009/8/18 Ian Lance Taylor <iant@google.com>:
>>
>>>> +      obj->setup(ehdr);
>>>
>>> It no longer makes sense for Object::setup to take an ehdr parameter.
>>> It should take a target parameter, and avoid looking up the target
>>> again.
>>
>> Agree. I suppose all objects have targets and their targets do not
>> change.   Should setup() be simply part of the constructor?
>
> I originally left it out because it can fail, and it's weird to have a
> constructor fail.  I guess I'd prefer to keep it separate for now.
>
>
>>> Interesting problem.  I wonder if there is anything we can do to make
>>> that easier to write.
>>
>> Unfortunately, virtual functions cannot be templated.  That's why I
>> mentioned changing the paratmeter ehdr back to a raw unsigned char
>> pointer.  If we do so,  we only have one virtual function instead of
>> four.  The downside of doing that is that callers must ensure that the
>> pointer points to something valid.   Passing an
>> Elfcpp::Ehdr<size,big_endian> object enforces that automatically.
>
> Yeah, I guess the way you did it is fine.
>
> Ian
>