This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

Slight tree reorganization for cygming platforms


Hi,

I am playing(don't know if it's the right word) for a few months with a
modified gcc targeting
arm-wince-pe and I have noticed some ugly organization in files that force
to have multiple files
with in general only one or two differences.
For instance here is some part of our patch :

--- libgcc/config/arm/t-wince-pe	(revision 0)
+++ libgcc/config/arm/t-wince-pe	(revision 0)
@@ -0,0 +1,11 @@
+CUSTOM_CRTSTUFF = yes
+
+crtbegin.o: $(gcc_srcdir)/config/i386/cygming-crtbegin.c
+	$(crt_compile) -fno-omit-frame-pointer  -c \
+	$(gcc_srcdir)/config/i386/cygming-crtbegin.c

so as you can see even if we are working on a arm platform we are using a
file in i386.

--- gcc/config.gcc	(revision 144970)
+++ gcc/config.gcc	(working copy)
+arm-*-mingw32*)
+	tm_file="${tm_file} arm/semi.h arm/aout.h arm/coff.h dbxcoff.h arm/pe.h
arm/wince-pe.h arm/mingw32.h"
+ 	# xm_file=arm/xm-mingw32.h
+ 	# This has to match the logic for DWARF2_UNWIND_INFO in
gcc/config/i386/cygming.h
+	if test x$sjlj = x0; then
+		tmake_eh_file="i386/t-dw2-eh"
+	else
+		tmake_eh_file="i386/t-sjlj-eh"
+	fi
+ 	tmake_file="${tmake_file} ${tmake_eh_file} arm/t-arm arm/t-wince-pe
arm/t-cygming arm/t-mingw32"
+ 	target_gtfiles="\$(srcdir)/config/arm/pe.c"
+ 	extra_options="${extra_options} arm/pe.opt arm/cygming.opt"
+ 	extra_objs="pe.o pe-stubs.o"
+	c_target_objs="${c_target_objs} \$(srcdir)/config/i386/msformat-c.o"
+ 	cxx_target_objs="pe-cxx.o \$(srcdir)/config/i386/msformat-c.o"
+	default_use_cxa_atexit=yes
+ 	case ${enable_threads} in
+ 	  "" | yes | win32)
+ 	  thread_file='win32'
+	  tmake_file="${tmake_file} i386/t-gthr-win32"
+ 	  ;;
+ 	esac

Once again we are  referencing i386/t-gthr-win32, i386/t-dw2-eh and
i386/t-sjlj-eh 
and this is stupid because those files have only one definition that is not
i386 specific.

I will show with a last example but I could continue like that with more
cases :

--- gcc/config/arm/t-wince-pe	(revision 144970)
+++ gcc/config/arm/t-wince-pe	(working copy)
@@ -20,12 +20,34 @@
 	echo '#endif' >> dp-bit.c
 	cat $(srcdir)/config/fp-bit.c >> dp-bit.c
 
...
+#hack! using i386 file directly...
+msformat-c.o: $(srcdir)/config/i386/msformat-c.c $(CONFIG_H) $(SYSTEM_H)
coretypes.h \
+  $(TM_H) $(RTL_H) $(REGS_H) hard-reg-set.h output.h $(TREE_H) flags.h \
+  $(TM_P_H) toplev.h $(HASHTAB_H) $(GGC_H)
+	$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
+	$(srcdir)/config/i386/msformat-c.c 

Once again we are referencing a file in i386 that is not specific ...


What I propose is to reorganize a bit files for ms support and to put
together common
declaration and stop to consider it as i386 specific.
Couldn't be more clever to create a cygwmin folder with the following file
:

+cygmin
  t-gthr-win32
  msformat-c.c
  t-dw2-eh
  t-sjlj-eh
  mingw32.h

For information all the ms platforms are sharing lots of defintions and the
following platforms
could benefit from it because right now we are have to copy/paste for every
new ms derived platform
or reference files in i386 folder.

i386-w32 (win32)
i386-w64 (win64)
i386-wce (wince)
arm-wce (arm-wince-pe)
mips-wce(mips-wince-pe)

What do you think ? 


Vincent R.















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