OpenCores
Issue List
or1k 0.4.0 compile under cygwin #114
Closed Iguaner opened this issue almost 14 years ago
Iguaner commented almost 14 years ago

There is problem with compiling or1k 0.4.0. I tried compiling it manual and by install script and both give attached error report. I am using CygWin and I have no problem with compile or1k 0.3.0.

make all-recursive make1: Entering directory /home/Ondrej/or_chain/or32-build/or1ksim-0.4.0' Making all in argtable2 make[2]: Entering directory/home/Ondrej/or_chain/or32-build/or1ksim-0.4.0/argtable2' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../cpu/or32 -I.. -I../cpu/common -I../cpu/or1k -I../cache -I../mmu -I../bpb -I../peripheral -I../tick -I../peripheral/channels -I../pm -I../pic -I../debug -I../vapi -I../support -I../cuc -I../port -I../argtable2 -DNDEBUG -g -O2 -g -Wall -Werror -O2 -DOR32 -MT libargtable2_la-argtable2.lo -MD -MP -MF .deps/libargtable2_la-argtable2.Tpo -c -o libargtable2_la-argtable2.lo test -f 'argtable2.c' || echo './'argtable2.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../cpu/or32 -I.. -I../cpu/common -I../cpu/or1k -I../cache -I../mmu -I../bpb -I../peripheral -I../tick -I../peripheral/channels -I../pm -I../pic -I../debug -I../vapi -I../support -I../cuc -I../port -I../argtable2 -DNDEBUG -g -O2 -g -Wall -Werror -O2 -DOR32 -MT libargtable2_la-argtable2.lo -MD -MP -MF .deps/libargtable2_la-argtable2.Tpo -c argtable2.c -DDLL_EXPORT -DPIC -o .libs/libargtable2_la-argtable2.o argtable2.c: In function arg_print_formatted': argtable2.c:972: warning: array subscript has typechar' argtable2.c:981: warning: array subscript has type char' make[2]: *** [libargtable2_la-argtable2.lo] Error 1 make[2]: Leaving directory/home/Ondrej/or_chain/or32-build/or1ksim-0.4.0/argtable2' make1: all-recursive Error 1 make1: Leaving directory `/home/Ondrej/or_chain/or32-build/or1ksim-0.4.0' make: all Error 2

jeremybennett was assigned almost 14 years ago
jeremybennett commented almost 14 years ago
<p> I didn't test on Cygwin. This is the second report I have heard of this problem. </p> <p> I believe the work around is to change line 972 in argtable2/argtable2.c as follows: </p> <pre> while (isspace ((int) (*(text+line_start))) ) </pre> <p> and to change line 981 as follows. </p> <pre> && !isspace ((int) (*(text+line_end)))) </pre> <p> Would you make changes and verify that Or1ksim compiles OK for you. </p> <p> Thanks, </p> <p> jeremy </p> <p> -- <br /> Tel: +44 (1590) 610184<br /> Cell: +44 (7970) 676050<br /> SkypeID: jeremybennett<br /> Email: <a href="mailto:jeremy.bennett@embecosm.com">jeremy.bennett@embecosm.com</a><br /> Web: <a href="http://www.embecosm.com">www.embecosm.com</a> </p>
Iguaner commented almost 14 years ago

Hi

I have changed it as you said. The same problem was also in files or32.c and generate.c and sim_cmd.c. The problem is usually with function "isspace".

There is aslo problem with redefinition "MSG_DONTWAIT" in file eth.h on line 204.

Next problem was with file rsp-server.c. There I must change function "rsp_remove_matchpoint" at line 2234

static void rsp_remove_matchpoint (struct rsp_buf buf) { enum mp_type type; / What sort of matchpoint / unsigned long int addr; / Address specified / int len; / Matchpoint length (not used) / struct mp_entry mpe; / Info about the replaced instr / int tmp_en;

type = WP_ACCESS;

/ Break out the instruction / if (3 != sscanf (buf->data, "z%1d,%lx,%1d", /(int )&type/&tmp_en, &addr, &len)) { /(int) type = tmp_en; */ switch (tmp_en) { case 0: type = BP_MEMORY; break; case 1: type = BP_HARDWARE; break; case 2: type = WP_WRITE; break; case 3: type = WP_READ; break; case 4: type = WP_ACCESS; break;
default : type = WP_ACCESS; break;
}

  fprintf (stderr, "Warning: RSP matchpoint deletion request not "
       "recognized: ignored\n");
  put_str_packet ("E01");
  return;
}

Similar changes must be dove for function "rsp_insert_matchpoint" at line 2330. I am not 100% sure this change is OK.

With this changes it is possible to compile or1ksim 0.4.0. Now I test, if it work.

Iguaner commented almost 14 years ago

One more note - what version of gcc are you using? Becouse I am using under Cygwin gcc 3.4.4.

jeremybennett commented almost 14 years ago
<p> Thanks for the feedback. </p> <p> I am currently using GCC 4.4.1 on Fedora 11 and GCC 4.4.3 on Ubuntu 10.4. Looks like you are using a considerably older version of GCC - in general those are more forgiving, but not it seems in this case. </p> <p> How recently have you updated your Cygwin installation? I think you must be using quite an old version. </p> <p> I am surprised at the other problems, since I don't believe these have been changed since Or1ksim 0.3.0. </p> <p> I'll try installing GCC 3.4.4, and see if I can reproduce the problems on Fedora. </p> <p> Jeremy </p>
Iguaner commented almost 14 years ago

Its true, that I have about 1 year old verson of Cygwin and that time it doesnt support gcc 4.

jeremybennett commented almost 14 years ago
<p> Thanks for the additional information. I rarely use Windows now, so I haven't installed Cygwin. GCC 3.4.4 dates from 2004. I didn't realize it had stayed the default in Cygwin for so long. </p> <p> I have GCC 3.4.4 building on my machine at the moment, so I can test it. More news shortly. </p> <p> Jeremy </p> <p> (If you have access to IRC, then we can talk at freenode.net on channel #opencores.) </p>
jeremybennett commented almost 14 years ago
<p> OK. GCC 3.4.4 does barf in rsp_remove_matchpoint and rsp_insert_matchpoint. It has a problem dereferencing an enum variable can converting it to an integer pointer, since enums are really integers anyway (the "type punning" issue). </p> <p> I'm not sure why you didn't get his in Or1ksim 0.3.0, since I didn't think this code had changed. </p> <p> Almost certainly I could just remove the cast, but I like to make it clear what's going on. Here is my suggested change for rsp_remove_matchpoint at line 2234: </p> <pre> static void rsp_remove_matchpoint (struct rsp_buf *buf) { enum mp_type type; /* What sort of matchpoint */ int type_for_scanf; /* To avoid old GCC limitations */ unsigned long int addr; /* Address specified */ int len; /* Matchpoint length (not used) */ struct mp_entry *mpe; /* Info about the replaced instr */

/ Break out the instruction. We have to use an intermediary for the type, since older GCCs do not like taking the address of an enum (dereferencing type-punned pointer). / if (3 != sscanf (buf->data, "z%1d,%lx,%1d", &type_for_scanf, &addr, &len)) { fprintf (stderr, "Warning: RSP matchpoint deletion request not " "recognized: ignored\n"); put_str_packet ("E01"); return; }

type = type_for_scanf;

/ Sanity check that the length is 4 / if (4 != len)

</pre> <p> Here is the change for rsp_insert_matchpoint at line 2330. </p> <pre> static void rsp_insert_matchpoint (struct rsp_buf *buf) { enum mp_type type; /* What sort of matchpoint */ int type_for_scanf; /* To avoid old GCC limitations */ unsigned long int addr; /* Address specified */ int len; /* Matchpoint length (not used) */

/ Break out the instruction. We have to use an intermediary for the type, since older GCCs do not like taking the address of an enum (dereferencing type-punned pointer). / if (3 != sscanf (buf->data, "Z%1d,%lx,%1d", &type_for_scanf, &addr, &len)) { fprintf (stderr, "Warning: RSP matchpoint insertion request not " "recognized: ignored\n"); put_str_packet ("E01"); return; }

type = type_for_scanf;

/ Sanity check that the length is 4 / if (4 != len)

</pre> <p> This should cure the problem - let me know if you still have problems. I'll check this into SVN and it will get rolled into the next release. </p> <p> Thanks for reporting the problem. </p> <p> Jeremy </p>
jeremybennett commented almost 14 years ago
<p> Fixed in SVN top of tree. </p> <p> Marking closed. </p> <p> Jeremy </p>
jeremybennett closed this almost 14 years ago

Assignee
jeremybennett
Labels
Bug