* Re: Troubles building cris target [not found] <vt27jk8r372.fsf@zenia.home> @ 2005-03-15 23:09 ` Hans-Peter Nilsson 2005-03-16 17:57 ` Jim Blandy 0 siblings, 1 reply; 5+ messages in thread From: Hans-Peter Nilsson @ 2005-03-15 23:09 UTC (permalink / raw) To: jimb; +Cc: cgen, orjan.friberg, gdb > From: Jim Blandy <jimb@redhat.com> > Date: 15 Mar 2005 16:48:01 -0500 > When I try to build the GDB/sim sources from sources.redhat.com CVS on > an AMD64 Fedora Core 2 system, the build dies trying to link the > sim/cris/run executable with the errors below. JFTR, I built sim successfully on i686-pc-linux-gnu (FC2) with CVS as of "Tue Mar 15 15:09:24 UTC 2005". > This looks simple to fix, but I haven't followed it through. CGEN bugs are simple? Let's talk. > gcc -DHAVE_CONFIG_H -DWITH_DEFAULT_MODEL='"crisv32"' -DPROFILE=1 -DWITH_PROFILE=-1 -DWITH_ALIGNMENT=NONSTRICT_ALIGNMENT -DWITH_ENVIRONMENT=ALL_ENVIRONMENT -DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DWITH_SCACHE=16384 -I. -I/home/jimb/gdb/src/sim/cris -I../common -I/home/jimb/gdb/src/sim/cris/../common -I../../include -I/home/jimb/gdb/src/sim/cris/../../include -I../../bfd -I/home/jimb/gdb/src/sim/cris/../../bfd -I../../opcodes -I/home/jimb/gdb/src/sim/cris/../../opcodes -I../../intl -I/home/jimb/gdb/src/sim/cris/../../intl -g3 -o run \ > nrun.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a ../../libiberty/libiberty.a -lnsl > libsim.a(mloopv10f.o)(.text+0x3c2b): In function `crisv10f_engine_run_full': > /home/jimb/gdb/src/sim/cris/semcrisv10f-switch.c:1285: undefined reference to `ADDCSI' > libsim.a(mloopv10f.o)(.text+0x3ff2):/home/jimb/gdb/src/sim/cris/semcrisv10f-switch.c:1348: undefined reference to `SUBCSI' Can you please test this patch? 2005-03-16 Hans-Peter Nilsson <hp@axis.com> * cris/sim-main.h: Don't include cgen-ops.h. Define ANDIF specifically. --- sim-main.h Fri Jan 28 05:29:00 2005 +++ /tmp/sim-main.h Wed Mar 16 00:00:56 2005 @@ -57,8 +57,11 @@ do { \ #include "cgen-sim.h" #include "cris-sim.h" -/* For occurrences of ANDIF in decodev32.c. */ -#include "cgen-ops.h" +/* For occurrences of ANDIF in decodev32.c. We can't '#include + "cgen-ops.h"' here, as that'll break the outlining of operators in + sim/common/cgen-utils.c. FIXME: CGEN bug; there should be no ANDIF:s + in decodev32.c. */ +#define ANDIF(x, y) ((x) && (y)) \f struct cris_sim_mmapped_page { USI addr; brgds, H-P ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Troubles building cris target 2005-03-15 23:09 ` Troubles building cris target Hans-Peter Nilsson @ 2005-03-16 17:57 ` Jim Blandy 2005-03-16 18:25 ` Hans-Peter Nilsson 0 siblings, 1 reply; 5+ messages in thread From: Jim Blandy @ 2005-03-16 17:57 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: cgen, orjan.friberg, gdb Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes: > JFTR, I built sim successfully on i686-pc-linux-gnu (FC2) with > CVS as of "Tue Mar 15 15:09:24 UTC 2005". Hm. Our systems look identical except for the processor. Do you know why it builds for you, but not for me? > Can you please test this patch? > > 2005-03-16 Hans-Peter Nilsson <hp@axis.com> > > * cris/sim-main.h: Don't include cgen-ops.h. Define ANDIF specifically. It dies differently now: gcc -DHAVE_CONFIG_H -DWITH_DEFAULT_MODEL='"crisv32"' -DPROFILE=1 -DWITH_PROFILE=-1 -DWITH_ALIGNMENT=NONSTRICT_ALIGNMENT -DWITH_ENVIRONMENT=ALL_ENVIRONMENT -DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DWITH_SCACHE=16384 -I. -I/home/jimb/gdb/src/sim/cris -I../common -I/home/jimb/gdb/src/sim/cris/../common -I../../include -I/home/jimb/gdb/src/sim/cris/../../include -I../../bfd -I/home/jimb/gdb/src/sim/cris/../../bfd -I../../opcodes -I/home/jimb/gdb/src/sim/cris/../../opcodes -I../../intl -I/home/jimb/gdb/src/sim/cris/../../intl -g3 -o run \ nrun.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a ../../libiberty/libiberty.a -lnsl libsim.a(decodev10.o)(.text+0x771a): In function `crisv10f_decode': /home/jimb/gdb/src/sim/cris/decodev10.c:5059: undefined reference to `EXTHISI' libsim.a(decodev10.o)(.text+0x77fb):/home/jimb/gdb/src/sim/cris/decodev10.c:5087: undefined reference to `EXTHISI' libsim.a(decodev32.o)(.text+0x7219): In function `crisv32f_decode': /home/jimb/gdb/src/sim/cris/decodev32.c:4587: undefined reference to `EXTHISI' libsim.a(decodev32.o)(.text+0x72f7):/home/jimb/gdb/src/sim/cris/decodev32.c:4615: undefined reference to `EXTHISI' collect2: ld returned 1 exit status make[2]: *** [run] Error 1 make[2]: Leaving directory `/home/jimb/gdb/mbuild/cris-elf/sim/cris' make[1]: *** [all] Error 1 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Troubles building cris target 2005-03-16 17:57 ` Jim Blandy @ 2005-03-16 18:25 ` Hans-Peter Nilsson 2005-03-24 6:20 ` Hans-Peter Nilsson 2005-03-24 12:29 ` Frank Ch. Eigler 0 siblings, 2 replies; 5+ messages in thread From: Hans-Peter Nilsson @ 2005-03-16 18:25 UTC (permalink / raw) To: jimb; +Cc: hans-peter.nilsson, cgen, orjan.friberg, gdb > From: Jim Blandy <jimb@redhat.com> > Date: 16 Mar 2005 12:53:10 -0500 > Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes: > > JFTR, I built sim successfully on i686-pc-linux-gnu (FC2) with > > CVS as of "Tue Mar 15 15:09:24 UTC 2005". > > Hm. Our systems look identical except for the processor. Do you know > why it builds for you, but not for me? I can only assume that inlining limits are different. (Either we're using different GCC versions or inlining parameters for x86_64 trig differently.) The comment in the patch mentioned outlining of operator functions. Without the patch, they are never outlined, so if there's a call to the outlined function (as happened for you), it will not be found. > It dies differently now: > > gcc -DHAVE_CONFIG_H -DWITH_DEFAULT_MODEL='"crisv32"' -DPROFILE=1 -DWITH_PROFILE=-1 -DWITH_ALIGNMENT=NONSTRICT_ALIGNMENT -DWITH_ENVIRONMENT=ALL_ENVIRONMENT -DWITH_HOST_BYTE_ORDER=LITTLE_ENDIAN -DWITH_SCACHE=16384 -I. -I/home/jimb/gdb/src/sim/cris -I../common -I/home/jimb/gdb/src/sim/cris/../common -I../../include -I/home/jimb/gdb/src/sim/cris/../../include -I../../bfd -I/home/jimb/gdb/src/sim/cris/../../bfd -I../../opcodes -I/home/jimb/gdb/src/sim/cris/../../opcodes -I../../intl -I/home/jimb/gdb/src/sim/cris/../../intl -g3 -o run \ > nrun.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a ../../libiberty/libiberty.a -lnsl > libsim.a(decodev10.o)(.text+0x771a): In function `crisv10f_decode': > /home/jimb/gdb/src/sim/cris/decodev10.c:5059: undefined reference to `EXTHISI' Ugh. Looks like I'd need to #define EXTHISI too, perhaps others. But the obvious just dawned on me: the generated decode*.c should have an '#include "cgen-ops.h"'. Completely untested. CGENers, please comment. Decoding of instruction fields should be able to use the usual operators. Dunno if that's supposed to be handled elsewhere. Maybe this is related to the problem generating SID CPU files since about a year (reported before, no clue received). Ok to commit if it works? 2005-03-16 Hans-Peter Nilsson <hp@axis.com> * sim-decode.scm (cgen-decode.c): Include cgen-ops.h. Index: sim-decode.scm =================================================================== RCS file: /cvs/src/src/cgen/sim-decode.scm,v retrieving revision 1.9 diff -c -p -r1.9 sim-decode.scm *** sim-decode.scm 8 Jul 2003 16:19:35 -0000 1.9 --- sim-decode.scm 16 Mar 2005 18:17:07 -0000 *************** const IDESC * *** 582,587 **** --- 582,588 ---- #define WANT_CPU_@CPU@ #include \"sim-main.h\" + #include \"cgen-ops.h\" #include \"sim-assert.h\"\n\n" (lambda () (-gen-decode-insn-globals (non-multi-insns (non-alias-insns (current-insn-list))))) brgds, H-P ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Troubles building cris target 2005-03-16 18:25 ` Hans-Peter Nilsson @ 2005-03-24 6:20 ` Hans-Peter Nilsson 2005-03-24 12:29 ` Frank Ch. Eigler 1 sibling, 0 replies; 5+ messages in thread From: Hans-Peter Nilsson @ 2005-03-24 6:20 UTC (permalink / raw) To: cgen, gdb; +Cc: jimb > Date: Wed, 16 Mar 2005 19:24:21 +0100 > From: Hans-Peter Nilsson <hp@axis.com> > Ok to commit if it works? > > 2005-03-16 Hans-Peter Nilsson <hp@axis.com> > > * sim-decode.scm (cgen-decode.c): Include cgen-ops.h. That patch worked, as in compiles and cgen-utils.o contains the intended symbols for cris-sim. Calling again: any CGEN maintainer care to comment, perhaps approve? See earlier post for the obvious patch. For CRIS, removing the sim-main.h kludge as per below is necessary too. And of course, rebuilding decodev{10,32}.c is also necessary. Though until I get approval or other feedback from CGEN, I've instead committed the following horrible patch, which fixes up the generated decodev{10,32}.c after the fact but as soon as it's generated. (I couldn't find any system where gcc outlined some operator calls like what happens for Jim Blandy, but then again I don't have access to an amd64 system with FC2. SuSE's gcc-3.3.3 on amd64 does inline. Ditto gcc-3.2 and 3.4 for various hewlett-packard-testdrive systems.) Jim, please update and retry. I committed regen of all files; most changes in (other) regened files were the copyright blurb, but there seems to have been some gcc-4.0 fixes by Alan Modra. Can't be all bad. :-) Committed, after running the test-suite (which I haven't contributed yet, doh!) except the C tests. * cris/Makefile.in (stamp-v10fcpu, stamp-v32fcpu): Add kludge to include cgen-ops.h in decodev10.c and decodev32.c. * cris/sim-main.h: Don't include cgen-ops.h here. * cris/arch.c, cris/arch.h, cris/cpuall.h, cris/cpuv10.c, cris/cpuv10.h, cris/cpuv32.c, cris/cpuv32.h, cris/cris-desc.c, cris/cris-desc.h, cris/cris-opc.h, cris/decodev10.c, cris/decodev10.h, cris/decodev32.c, cris/decodev32.h, cris/modelv10.c, cris/modelv32.c, cris/semcrisv10f-switch.c, cris/semcrisv32f-switch.c: Regenerate. Index: sim-main.h =================================================================== RCS file: /cvs/src/src/sim/cris/sim-main.h,v retrieving revision 1.1 diff -p -c -u -p -r1.1 sim-main.h --- sim-main.h 28 Jan 2005 04:29:00 -0000 1.1 +++ sim-main.h 24 Mar 2005 06:06:03 -0000 @@ -56,9 +56,6 @@ do { \ #include "sim-base.h" #include "cgen-sim.h" #include "cris-sim.h" - -/* For occurrences of ANDIF in decodev32.c. */ -#include "cgen-ops.h" \f struct cris_sim_mmapped_page { USI addr; Index: Makefile.in =================================================================== RCS file: /cvs/src/src/sim/cris/Makefile.in,v retrieving revision 1.1 diff -p -c -u -p -r1.1 Makefile.in --- Makefile.in 28 Jan 2005 04:28:59 -0000 1.1 +++ Makefile.in 24 Mar 2005 06:06:03 -0000 @@ -140,11 +140,14 @@ stamp-arch: $(CGEN_READ_SCM) $(CGEN_ARCH touch stamp-arch arch.h arch.c cpuall.h: $(CGEN_MAINT) stamp-arch +# The sed-hack is supposed to be temporary, until we get CGEN to emit it. stamp-v10fcpu: $(CGEN_READ_SCM) $(CGEN_CPU_SCM) $(CGEN_DECODE_SCM) $(CGEN_CPU_DIR)/cris.cpu Makefile $(MAKE) cgen-cpu-decode $(CGEN_FLAGS_TO_PASS) \ archfile=$(CGEN_CPU_DIR)/cris.cpu \ cpu=crisv10f mach=crisv10 SUFFIX=v10 FLAGS="with-scache with-profile=fn" EXTRAFILES="$(CGEN_CPU_SEMSW)" $(SHELL) $(srcroot)/move-if-change $(srcdir)/semv10-switch.c $(srcdir)/semcrisv10f-switch.c + sed -ne 'p; s/^\(#include "sim-assert.h"\)$$/#include "cgen-ops.h"/p' < $(srcdir)/decodev10.c > decodev10.c.tmp + mv decodev10.c.tmp $(srcdir)/decodev10.c touch stamp-v10fcpu cpuv10.h cpuv10.c semcrisv10f-switch.c modelv10.c decodev10.c decodev10.h: $(CGEN_MAINT) stamp-v10fcpu @@ -153,6 +156,8 @@ stamp-v32fcpu: $(CGEN_READ_SCM) $(CGEN_C archfile=$(CGEN_CPU_DIR)/cris.cpu \ cpu=crisv32f mach=crisv32 SUFFIX=v32 FLAGS="with-scache with-profile=fn" EXTRAFILES="$(CGEN_CPU_SEMSW)" $(SHELL) $(srcroot)/move-if-change $(srcdir)/semv32-switch.c $(srcdir)/semcrisv32f-switch.c + sed -ne 'p; s/^\(#include "sim-assert.h"\)$$/#include "cgen-ops.h"/p' < $(srcdir)/decodev32.c > decodev32.c.tmp + mv decodev32.c.tmp $(srcdir)/decodev32.c touch stamp-v32fcpu cpuv32.h cpuv32.c semcrisv32f-switch.c modelv32.c decodev32.c decodev32.h: $(CGEN_MAINT) stamp-v32fcpu brgds, H-P ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Troubles building cris target 2005-03-16 18:25 ` Hans-Peter Nilsson 2005-03-24 6:20 ` Hans-Peter Nilsson @ 2005-03-24 12:29 ` Frank Ch. Eigler 1 sibling, 0 replies; 5+ messages in thread From: Frank Ch. Eigler @ 2005-03-24 12:29 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: cgen [-- Attachment #1: Type: text/plain, Size: 774 bytes --] Hi - HP wrote: > [...] > But the obvious just dawned on me: the generated decode*.c > should have an '#include "cgen-ops.h"'. Completely untested. > > CGENers, please comment. > > Decoding of instruction fields should be able to use the usual > operators. Dunno if that's supposed to be handled elsewhere. > Maybe this is related to the problem generating SID CPU files > since about a year (reported before, no clue received). CGEN has always been a little undisciplined about which of its RTL operators are permitted in which context (decode/extract/semantics). Since this is unlikely to change, please feel free to make whatever workable (i.e. tested) change (like getting cgen to add that #include), you need to make new ports work. - FChE [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-03-24 12:29 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <vt27jk8r372.fsf@zenia.home> 2005-03-15 23:09 ` Troubles building cris target Hans-Peter Nilsson 2005-03-16 17:57 ` Jim Blandy 2005-03-16 18:25 ` Hans-Peter Nilsson 2005-03-24 6:20 ` Hans-Peter Nilsson 2005-03-24 12:29 ` Frank Ch. Eigler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).