This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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] |
Here is an updated patch. -Doug 2010-02-02 Doug Kwan <dougkwan@google.com> * Makefile.am (HFILES): Add arm-reloc-property.h. (DEFFILES): New. (TARGETSOURCES): Add arm-reloc-property.cc (ALL_TARGETOBJS): Add arm-reloc-property.$(OBJEXT) (libgold_a_SOURCES): $(DEFFILES) * Makefile.in: Regenerate. * arm-reloc-property.cc: New file. * arm-reloc-property.h: New file. * arm-reloc.def: New file. * arm.cc: Update comments. (arm-reloc-property.h): New included header. (arm_reloc_property_table): New global variable. (Target_arm::do_select_as_default_target): New method definition. * configure.tgt (armeb*-*-*,armbe*-*-*,arm*-*-*): Add arm-reloc-property to targ_extra_obj. * parameters.cc (set_parameters_target): Call Target::select_as_default_target(). * target.h (Target::select_as_default_target): New method definition. (Target::do_select_as_default_target): Same. 2010/2/2 Doug Kwan (Ãö®¶¼w) <dougkwan@google.com>: > 2010/2/2 Ian Lance Taylor <iant@google.com>: > > >> I don't like the fact that we will pay in linker startup time for >> every linker which includes the ARM target, even if we are not >> linking ARM. This is problematic because by default the linker >> includes support for all targets. Can we arrange for this to only be >> constructed when the ARM target is being used? > > We can initialize this went we set the default target. That should be > MT-safe, right? > > >> Do we ever actually destroy a Tree_node structure? If not, there is >> no reason to have a destructor. > > We do. trees are temporary. We can keep them in the > Arm_reloc_property object but currently we have no further use. So I > delete a tree at the end of Arm_reloc_property's constructor. > >> If you keep this, s/for(/for (/ and s/<this/< this/ >> >> >>> + ~Arm_reloc_property_table() >>> + { >>> + for (size_t code = 0; code < Property_table_size; ++code) >>> + delete this->table_[code]; >>> + } >> >> Do we ever actually destroy an Arm_reloc_property_table? >> > > No. We can remove it. > >> This is a cute idea. Can you think of a way to make it a bit more >> general so that it is easier for other targets to use it? > > We can have a general way for all target but this is done in way so > that a part of arm-reloc.def is almost identical to a relocation code > table in the ARM ELF file format document. That is intentional, I > want it to be very easy to verify manually that the information in > arm-reloc.def is correct. Maybe we can use S-expression as the > common description language but there will still be quite a bit of > target-specific code in the analysis. I'm open to suggestions. > >> You need to arrange to add arm-reloc-property.$(OBJEXT) to targetobjs >> in gold/configure.ac when using --enable-target=arm. Look at how we >> set ${targ_obj}.\$(OBJEXT), where targ_obj is set in configure.tgt. > > ok. Will send an updated patch. > > The reason I want to do this is to make some parts of the ARM backend > more data driven. I remove code from arm.cc by adding more code > elsewhere :) > > -Doug >
Attachment:
patch-reloc-property.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |