* [ECOS] Wrongfully compiled code
@ 2008-01-07 23:59 ariga masahiro
2008-01-08 0:05 ` Gary Thomas
0 siblings, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-01-07 23:59 UTC (permalink / raw)
To: ecos-discuss
Hello,
Happy New Year.
Since there's suspicion that last mail being not successfully sent,
I send again.
If it was doubly sent I am soory.
I am encountered next phenomenon and I am very in deep trouble.
It happens when sending back TCP SYN-ACK packet to peer,
and it happens in
packages\net\bsd_tcpip\current\src\sys\netinet\tcp_output.c
tcp_output()function.
I attach C source code,and corresponding mixed source code below.
Please refer to them.
I traced source code using ICE. (numbers are source line numbers)
First,on line 398 hdrlen becomes 0x28.And optlen becomes 4 on line 408.
Althoug it should execute
512: hdrlen += optlen;
but looks it passed in C code trace.
And on line
| 643: m->m_len = hdrlen; -- hdrlen is still 0x28
hdrlen is 0x28,although it should be 0x2c.
I could have traced same part in mixed source mode,and I discovered it was
wrongfully compiled.
I explain in detail after the source code.
Below are C code source and corresponding mixed source(from 445 line onward
in C source).
-- tcp_output() C source code
383: send:
384: /*
385: * Before ESTABLISHED, force sending of initial options
386: * unless TCP set not to do any options.
387: * NOTE: we assume that the IP/TCP header plus TCP options
388: * always fit in a single mbuf, leaving room for a maximum
389: * link header, i.e.
390: * max_linkhdr + sizeof (struct tcpiphdr) + optlen <=
MCLBYTES
391: */
392: optlen = 0;
393: #ifdef INET6
394: if (isipv6)
395: hdrlen = sizeof (struct ip6_hdr) + sizeof (struct
tcphdr);
396: else
397: #endif
-> 398: hdrlen = sizeof (struct tcpiphdr); -- here hdrlen becomes
0x28
| 399: if (flags & TH_SYN) {
| 400: tp->snd_nxt = tp->iss;
| 401: if ((tp->t_flags & TF_NOOPT) == 0) {
402: u_short mss;
403:
| 404: opt[0] = TCPOPT_MAXSEG;
| 405: opt[1] = TCPOLEN_MAXSEG;
| 406: mss = htons((u_short) tcp_mssopt(tp));
| 407: (void)memcpy(opt + 2, &mss, sizeof(mss));
| 408: optlen = TCPOLEN_MAXSEG;
409:
| 410: if ((tp->t_flags & TF_REQ_SCALE) && --428,É"n,Ô
411: ((flags & TH_ACK) == 0 ||
412: (tp->t_flags & TF_RCVD_SCALE))) {
413: *((u_int32_t *)(opt + optlen)) = htonl(
414: TCPOPT_NOP << 24 |
415: TCPOPT_WINDOW << 16 |
416: TCPOLEN_WINDOW << 8 |
417: tp->request_r_scale);
418: optlen += 4;
419: }
420: }
421: }
422:
423: /*
424: * Send a timestamp and echo-reply if this is a SYN and our
side
425: * wants to use timestamps (TF_REQ_TSTMP is set) or both our
side
426: * and our peer have sent timestamps in our SYN's.
427: */
-> 428: if ((tp->t_flags & (TF_REQ_TSTMP|TF_NOOPT)) == TF_REQ_TSTMP
&&
429: (flags & TH_RST) == 0 &&
430: ((flags & TH_ACK) == 0 ||
431: (tp->t_flags & TF_RCVD_TSTMP))) {
432: u_int32_t *lp = (u_int32_t *)(opt + optlen);
433:
434: /* Form timestamp option as shown in appendix A of RFC
1323. */
435: *lp++ = htonl(TCPOPT_TSTAMP_HDR);
436: *lp++ = htonl(ticks);
437: *lp = htonl(tp->ts_recent);
438: optlen += TCPOLEN_TSTAMP_APPA;
439: }
440:
441: /*
442: * Send `CC-family' options if our side wants to use them
(TF_REQ_CC),
443: * options are allowed (!TF_NOOPT) and it's not a RST.
444: */
-> 445: if ((tp->t_flags & (TF_REQ_CC|TF_NOOPT)) == TF_REQ_CC &&
446: (flags & TH_RST) == 0) {
447: switch (flags & (TH_SYN|TH_ACK)) {
448: /*
449: * This is a normal ACK, send CC if we received CC
before
450: * from our peer.
451: */
452: case TH_ACK:
453: if (!(tp->t_flags & TF_RCVD_CC))
454: break;
455: /*FALLTHROUGH*/
456:
457: /*
458: * We can only get here in T/TCP's SYN_SENT* state, when
459: * we're a sending a non-SYN segment without waiting for
460: * the ACK of our SYN. A check above assures that we
only
461: * do this if our peer understands T/TCP.
462: */
463: case 0:
464: opt[optlen++] = TCPOPT_NOP;
465: opt[optlen++] = TCPOPT_NOP;
466: opt[optlen++] = TCPOPT_CC;
467: opt[optlen++] = TCPOLEN_CC;
468: *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);
469:
470: optlen += 4;
471: break;
472:
473: /*
474: * This is our initial SYN, check whether we have to use
475: * CC or CC.new.
476: */
477: case TH_SYN:
478: opt[optlen++] = TCPOPT_NOP;
479: opt[optlen++] = TCPOPT_NOP;
480: opt[optlen++] = tp->t_flags & TF_SENDCCNEW ?
481: TCPOPT_CCNEW : TCPOPT_CC;
482: opt[optlen++] = TCPOLEN_CC;
483: *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);
484: optlen += 4;
485: break;
486:
487: /*
488: * This is a SYN,ACK; send CC and CC.echo if we received
489: * CC from our peer.
490: */
491: case (TH_SYN|TH_ACK):
492: if (tp->t_flags & TF_RCVD_CC) {
493: opt[optlen++] = TCPOPT_NOP;
494: opt[optlen++] = TCPOPT_NOP;
495: opt[optlen++] = TCPOPT_CC;
496: opt[optlen++] = TCPOLEN_CC;
497: *(u_int32_t *)&opt[optlen] =
498: htonl(tp->cc_send);
499: optlen += 4;
500: opt[optlen++] = TCPOPT_NOP;
501: opt[optlen++] = TCPOPT_NOP;
502: opt[optlen++] = TCPOPT_CCECHO;
503: opt[optlen++] = TCPOLEN_CC;
504: *(u_int32_t *)&opt[optlen] =
505: htonl(tp->cc_recv);
506: optlen += 4;
507: }
508: break;
509: }
510: }
511:
512: hdrlen += optlen;
and try to convert m->m_len,
-> 642: m->m_data += max_linkhdr;
| 643: m->m_len = hdrlen; -- hdrlen is still 0x28
--- Mix source code corresponding to C code
tcp_output.c (445): if ((tp->t_flags & (TF_REQ_CC|TF_NOOPT)) == TF_REQ_CC
&&
8C048BA4 51AA MOV.L @(28,R10 tp ),R1
8C048BA6 9214 MOV.W 8C048BD2,R2
8C048BA8 2129 AND R2,R1
8C048BAA 72F8 ADD #F8,R2
8C048BAC 3120 CMP/EQ R2,R1
8C048BAE 8F51 BF/S
4 ->1
8C048BB0 60D3 MOV R13 flags ,R0
8C048BB2 C904 AND #4,R0
8C048BB4 2008 TST R0,R0
8C048BB6 8F4D BF/S 8C048C54
8C048BB8 E212 MOV #12,R2
tcp_output.c (447): switch (flags & (TH_SYN|TH_ACK)) {
8C048BBA 22D9 AND R13 flags ,R2
8C048BBC E112 MOV #12,R1
8C048BBE 3216 CMP/HI R1,R2
8C048BC0 8948 BT 8C048C54
8C048BC2 C70A MOVA 8C048BEC,R0
8C048BC4 322C ADD R2,R2
8C048BC6 012D MOV.W @(R0,R2),R1
8C048BC8 0123 BRAF R1
8C048BCA 0009 NOP
8C048BCC 00AC MOV.B @(R0,R10 tp ),R0
8C048BCE 0080 ???
8C048BD0 0100 ???
8C048BD2 2008 TST R0,R0
8C048BD4 8C02 ???
8C048BD6 9D60 MOV.W 8C048C9A,R13 flags
8C048BD8 8C04 ???
8C048BDA 94A0 MOV.W 8C048D1E,R4
8C048BDC 8C04 ???
8C048BDE 8600 ???
8C048BE0 0103 BSRF R1
8C048BE2 0300 ???
8C048BE4 0101 ???
8C048BE6 080A STS MACH,R8 error
8C048BE8 8C02 ???
8C048BEA 8BF0 BF 8C048BCE
8C048BEC 005C MOV.B @(R0,R5),R0
8C048BEE 0124 MOV.B R2,@(R0,R1)
8C048BF0 0094 MOV.B R9,@(R0,R0)
8C048BF2 0124 MOV.B R2,@(R0,R1)
8C048BF4 0124 MOV.B R2,@(R0,R1)
8C048BF6 0124 MOV.B R2,@(R0,R1)
8C048BF8 0124 MOV.B R2,@(R0,R1)
8C048BFA 0124 MOV.B R2,@(R0,R1)
8C048BFC 0124 MOV.B R2,@(R0,R1)
8C048BFE 0124 MOV.B R2,@(R0,R1)
8C048C00 0124 MOV.B R2,@(R0,R1)
8C048C02 0124 MOV.B R2,@(R0,R1)
8C048C04 0124 MOV.B R2,@(R0,R1)
8C048C06 0124 MOV.B R2,@(R0,R1)
8C048C08 0124 MOV.B R2,@(R0,R1)
8C048C0A 0124 MOV.B R2,@(R0,R1)
8C048C0C 0054 MOV.B R5,@(R0,R0)
8C048C0E 0124 MOV.B R2,@(R0,R1)
8C048C10 00D4 MOV.B R13 flags ,@(R0,R0)
8C048C12 0009 NOP
8C048C14 0009 NOP
8C048C16 0009 NOP
8C048C18 0009 NOP
8C048C1A 0009 NOP
8C048C1C 0009 NOP
8C048C1E 0009 NOP
tcp_output.c (453): if (!(tp->t_flags & TF_RCVD_CC))
8C048C20 52AA MOV.L @(28,R10 tp ),R2
8C048C22 91B2 MOV.W 8C048D8A,R1
8C048C24 2218 TST R1,R2
8C048C26 8963 BT 8C048CF0
tcp_output.c (464): opt[optlen++] = TCPOPT_NOP;
8C048C28 E101 MOV #1,R1
8C048C2A E048 MOV #48,R0
8C048C2C 00EE MOV.L @(R0,R14),R0
8C048C2E 0E14 MOV.B R1,@(R0,R14)
8C048C30 7001 ADD #1,R0
8C048C32 E240 MOV #40,R2
8C048C34 32EC ADD R14,R2
tcp_output.c (465): opt[optlen++] = TCPOPT_NOP;
8C048C36 0E14 MOV.B R1,@(R0,R14)
8C048C38 7001 ADD #1,R0
tcp_output.c (466): opt[optlen++] = TCPOPT_CC;
8C048C3A E10B MOV #B,R1
8C048C3C 0E14 MOV.B R1,@(R0,R14)
8C048C3E 7001 ADD #1,R0
tcp_output.c (467): opt[optlen++] = TCPOLEN_CC;
8C048C40 E106 MOV #6,R1
8C048C42 0E14 MOV.B R1,@(R0,R14)
8C048C44 7001 ADD #1,R0
8C048C46 1202 MOV.L R0,@(8,R2)
tcp_output.c (468): *(u_int32_t *)&opt[optlen] =
htonl(tp->cc_send);
8C048C48 90A0 MOV.W 8C048D8C,R0
8C048C4A 01AE MOV.L @(R0,R10 tp ),R1
8C048C4C 5022 MOV.L @(8,R2),R0
8C048C4E 0E16 MOV.L R1,@(R0,R14)
tcp_output.c (470): optlen += 4;
8C048C50 7004 ADD #4,R0
8C048C52 1202 MOV.L R0,@(8,R2)
->1 8C048C54 A04D BRA 8C048CF2 ->2
tcp_output.c (471): break;
8C048C56 E740 MOV #40,R7
8C048C58 0009 NOP
8C048C5A 0009 NOP
8C048C5C 0009 NOP
8C048C5E 0009 NOP
tcp_output.c (478): opt[optlen++] = TCPOPT_NOP;
8C048C60 E101 MOV #1,R1
8C048C62 E048 MOV #48,R0
8C048C64 00EE MOV.L @(R0,R14),R0
8C048C66 0E14 MOV.B R1,@(R0,R14)
8C048C68 7001 ADD #1,R0
tcp_output.c (479): opt[optlen++] = TCPOPT_NOP;
8C048C6A 0E14 MOV.B R1,@(R0,R14)
8C048C6C 7001 ADD #1,R0
tcp_output.c (480): opt[optlen++] = tp->t_flags & TF_SENDCCNEW ?
8C048C6E 6303 MOV R0,R3 ipoptlen
8C048C70 33EC ADD R14,R3 ipoptlen
8C048C72 7001 ADD #1,R0
8C048C74 52AA MOV.L @(28,R10 tp ),R2
8C048C76 D146 MOV.L 8C048D90,R1
8C048C78 2218 TST R1,R2
8C048C7A 0129 MOVT R1
8C048C7C 611B NEG R1,R1
8C048C7E 710C ADD #C,R1
8C048C80 2310 MOV.B R1,@R3 ipoptlen
tcp_output.c (482): opt[optlen++] = TCPOLEN_CC;
8C048C82 E106 MOV #6,R1
8C048C84 0E14 MOV.B R1,@(R0,R14)
8C048C86 7001 ADD #1,R0
8C048C88 E640 MOV #40,R6
8C048C8A 36EC ADD R14,R6
8C048C8C 1602 MOV.L R0,@(8,R6)
tcp_output.c (483): *(u_int32_t *)&opt[optlen] =
htonl(tp->cc_send);
8C048C8E 907D MOV.W 8C048D8C,R0
8C048C90 01AE MOV.L @(R0,R10 tp ),R1
8C048C92 A029 BRA 8C048CE8
tcp_output.c (485): break;
8C048C94 5062 MOV.L @(8,R6),R0
8C048C96 0009 NOP
8C048C98 0009 NOP
8C048C9A 0009 NOP
8C048C9C 0009 NOP
8C048C9E 0009 NOP
tcp_output.c (492): if (tp->t_flags & TF_RCVD_CC) {
8C048CA0 52AA MOV.L @(28,R10 tp ),R2
8C048CA2 9172 MOV.W 8C048D8A,R1
8C048CA4 2218 TST R1,R2
8C048CA6 8D24 BT/S 8C048CF2
8C048CA8 E740 MOV #40,R7
tcp_output.c (493): opt[optlen++] = TCPOPT_NOP;
8C048CAA E201 MOV #1,R2
8C048CAC E048 MOV #48,R0
8C048CAE 00EE MOV.L @(R0,R14),R0
8C048CB0 0E24 MOV.B R2,@(R0,R14)
8C048CB2 7001 ADD #1,R0
tcp_output.c (494): opt[optlen++] = TCPOPT_NOP;
8C048CB4 0E24 MOV.B R2,@(R0,R14)
8C048CB6 7001 ADD #1,R0
tcp_output.c (495): opt[optlen++] = TCPOPT_CC;
8C048CB8 E10B MOV #B,R1
8C048CBA 0E14 MOV.B R1,@(R0,R14)
8C048CBC 7001 ADD #1,R0
8C048CBE E640 MOV #40,R6
8C048CC0 36EC ADD R14,R6
tcp_output.c (496): opt[optlen++] = TCPOLEN_CC;
8C048CC2 E706 MOV #6,R7
8C048CC4 0E74 MOV.B R7,@(R0,R14)
8C048CC6 7001 ADD #1,R0
tcp_output.c (497): *(u_int32_t *)&opt[optlen] =
8C048CC8 9160 MOV.W 8C048D8C,R1
8C048CCA 63A3 MOV R10 tp ,R3 ipoptlen
8C048CCC 331C ADD R1,R3 ipoptlen
8C048CCE 5130 MOV.L @(0,R3 ipoptlen ),R1
8C048CD0 0E16 MOV.L R1,@(R0,R14)
tcp_output.c (499): optlen += 4;
8C048CD2 7004 ADD #4,R0
tcp_output.c (500): opt[optlen++] = TCPOPT_NOP;
8C048CD4 0E24 MOV.B R2,@(R0,R14)
8C048CD6 7001 ADD #1,R0
tcp_output.c (501): opt[optlen++] = TCPOPT_NOP;
8C048CD8 0E24 MOV.B R2,@(R0,R14)
8C048CDA 7001 ADD #1,R0
tcp_output.c (502): opt[optlen++] = TCPOPT_CCECHO;
8C048CDC E10D MOV #D,R1
8C048CDE 0E14 MOV.B R1,@(R0,R14)
8C048CE0 7001 ADD #1,R0
tcp_output.c (503): opt[optlen++] = TCPOLEN_CC;
8C048CE2 0E74 MOV.B R7,@(R0,R14)
8C048CE4 7001 ADD #1,R0
tcp_output.c (504): *(u_int32_t *)&opt[optlen] =
8C048CE6 5131 MOV.L @(4,R3 ipoptlen ),R1
8C048CE8 0E16 MOV.L R1,@(R0,R14)
tcp_output.c (506): optlen += 4;
8C048CEA 7004 ADD #4,R0
8C048CEC 1602 MOV.L R0,@(8,R6)
8C048CEE 0009 NOP
tcp_output.c (512): hdrlen += optlen;
8C048CF0 E740 MOV #40,R7
->2 8C048CF2 37EC ADD R14,R7
8C048CF4 5073 MOV.L @(C,R7),R0
8C048CF6 5772 MOV.L @(8,R7),R7
8C048CF8 307C ADD R7,R0
8C048CFA 1703 MOV.L R0,@(C,R7)
tcp_output.c (520): if (tp->t_inpcb->inp_options) {
8C048CFC 51A8 MOV.L @(20,R10 tp ),R1
8C048CFE 9046 MOV.W 8C048D8E,R0
8C048D00 011E MOV.L @(R0,R1),R1
8C048D02 2118 TST R1,R1
8C048D04 8904 BT 8C048D10
8C048D06 5113 MOV.L @(C,R1),R1
tcp_output.c (521): ipoptlen = tp->t_inpcb->inp_options->m_len -
In detail.
Like I said,at line-445 hdrlen is 0x28,and optlen is 4.
After that it jump to address 8C048CF2(->2).
About @(disp:4,Rn) assembler operation,next is from SH assembler manual,
"The effective address is Rn plus a 4-bit displacement
(disp). The value of disp is zero-extended, and
remains the same for a byte operation, is doubled for
a word operation, and is quadrupled for a longword
operation."
When jumped to 8C048CF2, R14=8c081458,R7=00000040.
Added,R7 becomes 8c081498.
After executing (MOV.L @(C,R7),R0),R0 becomes 0x28.
But here it acts qeerly,according to manual,0x28 should be retrieved
from 8c081498+c*4=8c0814c8, but really it was retreived from 8c0814a4.
It looks there's no extension according to operand size.But this is minor
point.
Anyway,after executing next line(MOV.L @(8,R7),R7),R7 becomes 4.
By (ADD R7,R0),R0 becomes 0x2c,this is expected value for hdrlen.
But,by (MOV.L R0,@(C,R7)),content of R0 is reserved into 0x00000010.(really
it can't be written).
Content of hdrlen(8c0814a4) remains 0x28.
I executed without ICE but resulted in IP packet size being 0x28,although it
should be 0x2c.
I am perplexed why this phenomenon happens.
Please enlighten me what do you think causes this mishappening.
My target CPU is SH7709S.
I am developing on Cygwin environment.
I checked sh-elf-gcc version and it was version 3.2.1.
$ sh-elf-gcc -v
Reading specs from
/opt/ecos/gnutools/sh-elf/bin/../lib/gcc-lib/sh-elf/3.2.1/spe
cs
Configured with:
/local/demonweb/tools/ecos-gnutools-v1.4/r2/sh-elf/cygwin/tar_b
z2/source/gcc-3.2.1/configure --target=sh-elf --prefix=/local/demonweb/tools/eco
s-gnutools-v1.4/r2/sh-elf/cygwin/tar_bz2/opt/ecos/gnutools/sh-elf --enable-langu
ages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-gxx-include-dir=/loc
al/demonweb/tools/ecos-gnutools-v1.4/r2/sh-elf/cygwin/tar_bz2/opt/ecos/gnutools/
sh-elf/sh-elf/include
Thread model: single
gcc version 3.2.1
My compile option is same as CVS downloaded version for se77x9,
cdl_option CYGBLD_GLOBAL_CFLAGS {
display "Global compiler flags"
flavor data
no_define
default_value { CYGHWR_HAL_SH_BIGENDIAN ?
"-D_KERNEL -D__ECOS -mb -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline
-Wundef -Woverloaded-virtual -ggdb -O1 -ffunction-sections -fdata-sections
-fno-rtti -fno-exceptions -fvtable-gc -finit-priority" :
"-D_KERNEL -D__ECOS -ml -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline
-Wundef -Woverloaded-virtual -ggdb -O1 -ffunction-sections -fdata-sections
-fno-rtti -fno-exceptions -fvtable-gc -finit-priority" }
description "
This option controls the global compiler flags which
are used to compile all packages by
default. Individual packages may define
options which override these global flags."
}
cdl_option CYGBLD_GLOBAL_LDFLAGS {
display "Global linker flags"
flavor data
no_define
default_value { CYGHWR_HAL_SH_BIGENDIAN ?
"-mb -m3 -ggdb -nostdlib -Wl,--gc-sections -Wl,-static" :
"-ml -m3 -ggdb -nostdlib -Wl,--gc-sections -Wl,-static" }
description "
This option controls the global linker flags. Individual
packages may define options which override these global
flags."
}
CYGHWR_HAL_SH_BIGENDIAN is valid.
My ICE works on Windows so I would like to develop on Cygwin environment.
I bessech you to help me.
Thanks in advance.
Masahiro Ariga
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Wrongfully compiled code
2008-01-07 23:59 [ECOS] Wrongfully compiled code ariga masahiro
@ 2008-01-08 0:05 ` Gary Thomas
2008-01-08 1:05 ` ariga masahiro
2008-02-22 4:57 ` [ECOS] How to re-install newly compiled gnutools ariga masahiro
0 siblings, 2 replies; 41+ messages in thread
From: Gary Thomas @ 2008-01-08 0:05 UTC (permalink / raw)
To: ariga masahiro; +Cc: ecos-discuss
ariga masahiro wrote:
> Hello,
> Happy New Year.
>
> Since there's suspicion that last mail being not successfully sent,
> I send again.
> If it was doubly sent I am soory.
Your message did indeed get sent yesterday.
Your problem seems to be related to GCC, not eCos per se.
The code that you are having trouble with compiles and works
properly on other architectures.
What version of GCC & BINUTILS are you using?
Have you tried using the versions recommended on the eCos
getting started page(s)?
For the most part though, I'd suggest that you try getting
help from the GCC world.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Wrongfully compiled code
2008-01-08 0:05 ` Gary Thomas
@ 2008-01-08 1:05 ` ariga masahiro
2008-01-17 19:21 ` [ECOS] " Dave Lawrence
2008-02-22 4:57 ` [ECOS] How to re-install newly compiled gnutools ariga masahiro
1 sibling, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-01-08 1:05 UTC (permalink / raw)
To: Gary Thomas; +Cc: ecos-discuss
Hello,Gary,others,
Thank you for your reply.
Forgive me troubling you by a few question.
> What version of GCC & BINUTILS are you using?
> Have you tried using the versions recommended on the eCos
> getting started page(s)?
I installed toolchain by downloading ecos-install.tcl.
That I got using next command on Cygwin.
$ wget --passive-ftp ftp://ecos.sourceware.org/pub/ecos/ecos-install.tcl
Do you mean this method is depreciated ?
And sh-elf-gcc version installed by above method is,
like I said,
$ sh-elf-gcc -v
Reading specs from
/opt/ecos/gnutools/sh-elf/bin/../lib/gcc-lib/sh-elf/3.2.1/spe
cs
Configured with:
/local/demonweb/tools/ecos-gnutools-v1.4/r2/sh-elf/cygwin/tar_b
z2/source/gcc-3.2.1/configure --target=sh-elf --prefix=/local/demonweb/tools/eco
s-gnutools-v1.4/r2/sh-elf/cygwin/tar_bz2/opt/ecos/gnutools/sh-elf --enable-langu
ages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-gxx-include-dir=/loc
al/demonweb/tools/ecos-gnutools-v1.4/r2/sh-elf/cygwin/tar_bz2/opt/ecos/gnutools/
sh-elf/sh-elf/include
Thread model: single
gcc version 3.2.1
> For the most part though, I'd suggest that you try getting
> help from the GCC world.
I do not know which site I should refer to.
What site do you think is better,Cygwin site or GCC site ?
I am sorry to trouble you,but please help me.
Masahiro Ariga
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* [ECOS] Re: Wrongfully compiled code
2008-01-08 1:05 ` ariga masahiro
@ 2008-01-17 19:21 ` Dave Lawrence
2008-01-17 23:50 ` ariga masahiro
0 siblings, 1 reply; 41+ messages in thread
From: Dave Lawrence @ 2008-01-17 19:21 UTC (permalink / raw)
To: ecos-discuss
> sh-elf/sh-elf/include
> Thread model: single
> gcc version 3.2.1
We found a bug in this version (probably the same one). I managed to
compile GCC 4.1.1 using the following sources
binutils 2.16
Newlib 1.14.0 (copy this to inside the GCC source directory)
Gcc 4.1.1
I had to make one hack to the configure file. It fails on a test, but
you can proceed without it, you'll just have to inspect the file when
the problem occurs and comment out that test. I can't remember any more
details than that sorry.
binutils is compiled separately. Newlib is not strictly needed by ecos
but I found GCC wouldn't compile without it (use the --with-newlib
option in the configure).
btw the compile time is measured in hours (about 4.5 on the PC I used)
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: Wrongfully compiled code
2008-01-17 19:21 ` [ECOS] " Dave Lawrence
@ 2008-01-17 23:50 ` ariga masahiro
2008-01-18 12:16 ` Dave Lawrence
0 siblings, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-01-17 23:50 UTC (permalink / raw)
To: ecos-discuss, Dave Lawrence
Hello,
Thank you very much for your confirmation.
I am much relieved to have found the cause of trouble.
But I do not know how to re-install sh-elf-gcc on Cygwin.
Could you please teach me how to do it ?
Masahiro Ariga
>
>> sh-elf/sh-elf/include
>> Thread model: single
>> gcc version 3.2.1
>
> We found a bug in this version (probably the same one). I managed to
> compile GCC 4.1.1 using the following sources
>
> binutils 2.16
> Newlib 1.14.0 (copy this to inside the GCC source directory)
> Gcc 4.1.1
>
> I had to make one hack to the configure file. It fails on a test, but
> you can proceed without it, you'll just have to inspect the file when
> the problem occurs and comment out that test. I can't remember any more
> details than that sorry.
>
> binutils is compiled separately. Newlib is not strictly needed by ecos
> but I found GCC wouldn't compile without it (use the --with-newlib
> option in the configure).
>
> btw the compile time is measured in hours (about 4.5 on the PC I used)
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: Wrongfully compiled code
2008-01-17 23:50 ` ariga masahiro
@ 2008-01-18 12:16 ` Dave Lawrence
2008-01-18 14:40 ` Gregg Levine
` (2 more replies)
0 siblings, 3 replies; 41+ messages in thread
From: Dave Lawrence @ 2008-01-18 12:16 UTC (permalink / raw)
To: ariga masahiro; +Cc: ecos-discuss
[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]
ariga masahiro wrote:
> Hello,
>
> Thank you very much for your confirmation.
> I am much relieved to have found the cause of trouble.
>
> But I do not know how to re-install sh-elf-gcc on Cygwin.
> Could you please teach me how to do it ?
>
> Masahiro Ariga
I found no pre-built version of GCC for this target available for download.
It's 18 months since I built it, and I've only ever built GCC once, so
I'm just
going off the top of my head, but I did save a python script which goes
through
the steps of building binutils and GCC. I've also generated a patch for
the configure
hack there are two versions attached, "configure.patch" was created
using SVN
(from the root of that tag) "patch" was created using diff.
You will need the cygwin build of Python installed via the standard
cygwin installer program from
cygwin.com
The GCC release can be obtained from SVN
svn co svn://gcc.gnu.org/svn/gcc/tags/gcc_4_1_1_release gcc_4_1_1
If you don't have SVN search their website for a tarball.
Obtain the aforementioned versions of newlib and binutils (you'll have
to search for these
the gcc website and/or google will get you there pretty quickly) and
unpack them such
that you have the following directory layout
./gcc_4_1_1
./gcc_4_1_1/newlib
./binutils-2.16
./buildall.py
./patch
./configure.patch
Either apply configure.patch using SVN (and I have no idea how to do
that from the
command line version) or apply "patch" using :
patch gcc_4_1_1/libstdc++-v3/configure -ipatch
Let's assume you want to install to /opt/ecos/gcc411:
run the attached script as
python buildall.py /opt/ecos/gcc411
*
*see also
http://gcc.gnu.org/install/
Good luck!*
*
>>
>>> sh-elf/sh-elf/include
>>> Thread model: single
>>> gcc version 3.2.1
>>
>> We found a bug in this version (probably the same one). I managed to
>> compile GCC 4.1.1 using the following sources
>>
>> binutils 2.16
>> Newlib 1.14.0 (copy this to inside the GCC source directory)
>> Gcc 4.1.1
>>
>> I had to make one hack to the configure file. It fails on a test,
>> but you can proceed without it, you'll just have to inspect the file
>> when the problem occurs and comment out that test. I can't remember
>> any more details than that sorry.
>>
>> binutils is compiled separately. Newlib is not strictly needed by
>> ecos but I found GCC wouldn't compile without it (use the
>> --with-newlib option in the configure).
>>
>> btw the compile time is measured in hours (about 4.5 on the PC I used)
>>
>>
>> --
>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>
>>
>
[-- Attachment #2: configure.patch --]
[-- Type: text/plain, Size: 1208 bytes --]
Index: libstdc++-v3/configure
===================================================================
--- libstdc++-v3/configure (revision 114326)
+++ libstdc++-v3/configure (working copy)
@@ -4576,6 +4576,8 @@
ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
ac_compiler_gnu=$ac_cv_c_compiler_gnu
+gcc_no_link=yes
+
if test x$gcc_no_link = xyes; then
{ { echo "$as_me:$LINENO: error: Link tests are not allowed after GCC_NO_EXECUTABLES." >&5
echo "$as_me: error: Link tests are not allowed after GCC_NO_EXECUTABLES." >&2;}
@@ -87646,6 +87648,8 @@
fi
fi
+gcc_no_link=no
+
# Check to see if 'gnu' can win.
if test $enable_symvers = gnu; then
# Check to see if libgcc_s exists, indicating that shared libgcc is possible.
@@ -87700,6 +87704,7 @@
echo "$as_me: failed program was:" >&5
sed 's/^/| /' conftest.$ac_ext >&5
+gcc_no_link=no
glibcxx_shared_libgcc=no
fi
rm -f conftest.err conftest.$ac_objext \
@@ -88575,6 +88580,8 @@
echo "${ECHO_T}$glibcxx_cv_func_setenv_use" >&6
if test x$glibcxx_cv_func_setenv_use = x"yes"; then
+gcc_no_link=no
+
for ac_func in setenv
do
as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
[-- Attachment #3: buildall.py --]
[-- Type: text/plain, Size: 1022 bytes --]
#!/usr/bin/python
import os
import sys
def do(cmd):
err = os.system(cmd)
if (err != 0):
sys.exit(err)
if sys.platform != "cygwin":
print "This script is for a cygwin build environment"
sys.exit(-1)
try:
outdir = sys.argv[1]
except:
print "Please specify output directory for built toolchain"
sys.exit(-1)
startdir = os.getcwd()
if True:
do("mkdir -p /tmp/build/binutils")
os.chdir("/tmp/build/binutils")
do("%s/binutils-2.16/configure --target=sh-elf --prefix=%s -v 2>&1 | tee binconfig.out" % (startdir, outdir))
do("make -w all install 2>&1 | tee binmake.out")
#sys.exit(0)
savepath = os.environ["PATH"]
os.environ["PATH"] = "%s/bin:%s" %(outdir, savepath)
do("mkdir -p /tmp/build/gcc")
os.chdir("/tmp/build/gcc")
do("%s/gcc_4_1_1/configure --target=sh-elf --prefix=%s --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-gxx-include-dir=%s/sh-elf/include --with-ecos -v 2>&1 | tee configgcc.txt " %(startdir, outdir, outdir))
do("make -w all install 2>&1 | tee makegcc.txt")
[-- Attachment #4: patch --]
[-- Type: text/plain, Size: 142 bytes --]
4578a4579,4580
> gcc_no_link=yes
>
87648a87651,87652
> gcc_no_link=no
>
87702a87707
> gcc_no_link=no
88577a88583,88584
> gcc_no_link=no
>
[-- Attachment #5: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: Wrongfully compiled code
2008-01-18 12:16 ` Dave Lawrence
@ 2008-01-18 14:40 ` Gregg Levine
2008-01-18 15:44 ` Dave Lawrence
2008-01-21 0:34 ` ariga masahiro
2008-02-04 1:49 ` ariga masahiro
2 siblings, 1 reply; 41+ messages in thread
From: Gregg Levine @ 2008-01-18 14:40 UTC (permalink / raw)
To: Dave Lawrence; +Cc: ariga masahiro, ecos-discuss
2008/1/18 Dave Lawrence <dlawrence@ad-holdings.co.uk>:
> ariga masahiro wrote:
> > Hello,
> >
> > Thank you very much for your confirmation.
> > I am much relieved to have found the cause of trouble.
> >
> > But I do not know how to re-install sh-elf-gcc on Cygwin.
> > Could you please teach me how to do it ?
> >
> > Masahiro Ariga
> I found no pre-built version of GCC for this target available for download.
> It's 18 months since I built it, and I've only ever built GCC once, so
> I'm just
> going off the top of my head, but I did save a python script which goes
> through
> the steps of building binutils and GCC. I've also generated a patch for
> the configure
> hack there are two versions attached, "configure.patch" was created
> using SVN
> (from the root of that tag) "patch" was created using diff.
>
> You will need the cygwin build of Python installed via the standard
> cygwin installer program from
> cygwin.com
>
> The GCC release can be obtained from SVN
> svn co svn://gcc.gnu.org/svn/gcc/tags/gcc_4_1_1_release gcc_4_1_1
> If you don't have SVN search their website for a tarball.
> Obtain the aforementioned versions of newlib and binutils (you'll have
> to search for these
> the gcc website and/or google will get you there pretty quickly) and
> unpack them such
> that you have the following directory layout
>
> ./gcc_4_1_1
> ./gcc_4_1_1/newlib
> ./binutils-2.16
> ./buildall.py
> ./patch
> ./configure.patch
>
> Either apply configure.patch using SVN (and I have no idea how to do
> that from the
> command line version) or apply "patch" using :
> patch gcc_4_1_1/libstdc++-v3/configure -ipatch
>
> Let's assume you want to install to /opt/ecos/gcc411:
> run the attached script as
> python buildall.py /opt/ecos/gcc411
> *
> *see also
> http://gcc.gnu.org/install/
>
> Good luck!*
>
> *
> >>
> >>> sh-elf/sh-elf/include
> >>> Thread model: single
> >>> gcc version 3.2.1
> >>
> >> We found a bug in this version (probably the same one). I managed to
> >> compile GCC 4.1.1 using the following sources
> >>
> >> binutils 2.16
> >> Newlib 1.14.0 (copy this to inside the GCC source directory)
> >> Gcc 4.1.1
> >>
> >> I had to make one hack to the configure file. It fails on a test,
> >> but you can proceed without it, you'll just have to inspect the file
> >> when the problem occurs and comment out that test. I can't remember
> >> any more details than that sorry.
> >>
> >> binutils is compiled separately. Newlib is not strictly needed by
> >> ecos but I found GCC wouldn't compile without it (use the
> >> --with-newlib option in the configure).
> >>
> >> btw the compile time is measured in hours (about 4.5 on the PC I used)
> >>
> >>
> >> --
> >> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> >> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> >>
> >>
> >
>
>
> Index: libstdc++-v3/configure
> ===================================================================
> --- libstdc++-v3/configure (revision 114326)
> +++ libstdc++-v3/configure (working copy)
> @@ -4576,6 +4576,8 @@
> ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
> ac_compiler_gnu=$ac_cv_c_compiler_gnu
>
> +gcc_no_link=yes
> +
> if test x$gcc_no_link = xyes; then
> { { echo "$as_me:$LINENO: error: Link tests are not allowed after GCC_NO_EXECUTABLES." >&5
> echo "$as_me: error: Link tests are not allowed after GCC_NO_EXECUTABLES." >&2;}
> @@ -87646,6 +87648,8 @@
> fi
> fi
>
> +gcc_no_link=no
> +
> # Check to see if 'gnu' can win.
> if test $enable_symvers = gnu; then
> # Check to see if libgcc_s exists, indicating that shared libgcc is possible.
> @@ -87700,6 +87704,7 @@
> echo "$as_me: failed program was:" >&5
> sed 's/^/| /' conftest.$ac_ext >&5
>
> +gcc_no_link=no
> glibcxx_shared_libgcc=no
> fi
> rm -f conftest.err conftest.$ac_objext \
> @@ -88575,6 +88580,8 @@
> echo "${ECHO_T}$glibcxx_cv_func_setenv_use" >&6
> if test x$glibcxx_cv_func_setenv_use = x"yes"; then
>
> +gcc_no_link=no
> +
> for ac_func in setenv
> do
> as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
>
> #!/usr/bin/python
>
> import os
> import sys
>
> def do(cmd):
> err = os.system(cmd)
> if (err != 0):
> sys.exit(err)
>
> if sys.platform != "cygwin":
> print "This script is for a cygwin build environment"
> sys.exit(-1)
>
> try:
> outdir = sys.argv[1]
> except:
> print "Please specify output directory for built toolchain"
> sys.exit(-1)
>
> startdir = os.getcwd()
>
> if True:
> do("mkdir -p /tmp/build/binutils")
> os.chdir("/tmp/build/binutils")
> do("%s/binutils-2.16/configure --target=sh-elf --prefix=%s -v 2>&1 | tee binconfig.out" % (startdir, outdir))
> do("make -w all install 2>&1 | tee binmake.out")
>
> #sys.exit(0)
>
> savepath = os.environ["PATH"]
> os.environ["PATH"] = "%s/bin:%s" %(outdir, savepath)
> do("mkdir -p /tmp/build/gcc")
> os.chdir("/tmp/build/gcc")
> do("%s/gcc_4_1_1/configure --target=sh-elf --prefix=%s --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-gxx-include-dir=%s/sh-elf/include --with-ecos -v 2>&1 | tee configgcc.txt " %(startdir, outdir, outdir))
> do("make -w all install 2>&1 | tee makegcc.txt")
>
>
>
> 4578a4579,4580
> > gcc_no_link=yes
> >
> 87648a87651,87652
> > gcc_no_link=no
> >
> 87702a87707
> > gcc_no_link=no
> 88577a88583,88584
> > gcc_no_link=no
> >
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
Hello!
Eh? The tools used by eCos, all of them, can be re-installed by using
the exact same installer that was used to start things off.
Just select the SH processor tool set and you are off. Of course
you'll need to add the "-f" setting to the commands used to run the
installer.
--
Gregg C Levine gregg.drwho8@gmail.com
"This signature was once found posting rude
messages in English in the Moscow subway."
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: Wrongfully compiled code
2008-01-18 14:40 ` Gregg Levine
@ 2008-01-18 15:44 ` Dave Lawrence
2008-01-18 15:49 ` Gregg Levine
0 siblings, 1 reply; 41+ messages in thread
From: Dave Lawrence @ 2008-01-18 15:44 UTC (permalink / raw)
To: Gregg Levine; +Cc: ariga masahiro, ecos-discuss
Gregg Levine wrote:
> Hello!
> Eh? The tools used by eCos, all of them, can be re-installed by using
> the exact same installer that was used to start things off.
>
> Just select the SH processor tool set and you are off. Of course
> you'll need to add the "-f" setting to the commands used to run the
> installer.
>
>
Hi,
Well maybe I'm missing something but according to the original
message that still gets you 3.2.1 which we know to be faulty.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: Wrongfully compiled code
2008-01-18 15:44 ` Dave Lawrence
@ 2008-01-18 15:49 ` Gregg Levine
2008-01-18 16:09 ` Dave Lawrence
0 siblings, 1 reply; 41+ messages in thread
From: Gregg Levine @ 2008-01-18 15:49 UTC (permalink / raw)
To: Dave Lawrence; +Cc: ariga masahiro, ecos-discuss
On Jan 18, 2008 10:43 AM, Dave Lawrence <dlawrence@ad-holdings.co.uk> wrote:
> Gregg Levine wrote:
> > Hello!
> > Eh? The tools used by eCos, all of them, can be re-installed by using
> > the exact same installer that was used to start things off.
> >
> > Just select the SH processor tool set and you are off. Of course
> > you'll need to add the "-f" setting to the commands used to run the
> > installer.
> >
> >
>
> Hi,
> Well maybe I'm missing something but according to the original
> message that still gets you 3.2.1 which we know to be faulty.
>
>
Hello!
It is? Show me, even though I'm not from the state. I've used that
version for all of my Dreamcast efforts. And the only problems I had
were not software related. They were hardware based.
Now I freely admit there was one problem, and that was with using eCos
to produce redboot images in ELF form files rather then BIN form files
for sending to the unit, but that was related to how the tool was
setup first.
I believe the problem you are thinking of may have been fixed already.
However.....
--
Gregg C Levine gregg.drwho8@gmail.com
"This signature was once found posting rude
messages in English in the Moscow subway."
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: Wrongfully compiled code
2008-01-18 15:49 ` Gregg Levine
@ 2008-01-18 16:09 ` Dave Lawrence
0 siblings, 0 replies; 41+ messages in thread
From: Dave Lawrence @ 2008-01-18 16:09 UTC (permalink / raw)
To: Gregg Levine; +Cc: ariga masahiro, ecos-discuss
Gregg Levine wrote:
> On Jan 18, 2008 10:43 AM, Dave Lawrence <dlawrence@ad-holdings.co.uk> wrote:
>
>> Gregg Levine wrote:
>>
>>> Hello!
>>> Eh? The tools used by eCos, all of them, can be re-installed by using
>>> the exact same installer that was used to start things off.
>>>
>>> Just select the SH processor tool set and you are off. Of course
>>> you'll need to add the "-f" setting to the commands used to run the
>>> installer.
>>>
>>>
>>>
>> Hi,
>> Well maybe I'm missing something but according to the original
>> message that still gets you 3.2.1 which we know to be faulty.
>>
>>
>>
>
> Hello!
> It is? Show me, even though I'm not from the state. I've used that
> version for all of my Dreamcast efforts. And the only problems I had
> were not software related. They were hardware based.
>
>
1) Refer to the start of this thread
2) Refer to postings on this list and gcc bug list started by a
colleague of mine way back in 2004..
http://www.cygwin.com/ml/ecos-discuss/2004-02/msg00010.html
http://gcc.gnu.org/ml/gcc-bugs/2004-02/msg00530.html
> Now I freely admit there was one problem, and that was with using eCos
> to produce redboot images in ELF form files rather then BIN form files
> for sending to the unit, but that was related to how the tool was
> setup first.
>
> I believe the problem you are thinking of may have been fixed already.
> However.....
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: Wrongfully compiled code
2008-01-18 12:16 ` Dave Lawrence
2008-01-18 14:40 ` Gregg Levine
@ 2008-01-21 0:34 ` ariga masahiro
2008-02-04 1:49 ` ariga masahiro
2 siblings, 0 replies; 41+ messages in thread
From: ariga masahiro @ 2008-01-21 0:34 UTC (permalink / raw)
To: Dave Lawrence; +Cc: ecos-discuss
Hello every one,
Thank you,Dave, very much for your reply.
I will study a little and endeavor to re-install.
But I must find time between other jobs,
so it will take a little time.
I will report to you result after that.
Masahiro Ariga
> ariga masahiro wrote:
>> Hello,
>>
>> Thank you very much for your confirmation.
>> I am much relieved to have found the cause of trouble.
>>
>> But I do not know how to re-install sh-elf-gcc on Cygwin.
>> Could you please teach me how to do it ?
>>
>> Masahiro Ariga
> I found no pre-built version of GCC for this target available for
> download.
> It's 18 months since I built it, and I've only ever built GCC once, so
> I'm just
> going off the top of my head, but I did save a python script which goes
> through
> the steps of building binutils and GCC. I've also generated a patch for
> the configure
> hack there are two versions attached, "configure.patch" was created
> using SVN
> (from the root of that tag) "patch" was created using diff.
>
> You will need the cygwin build of Python installed via the standard
> cygwin installer program from
> cygwin.com
>
> The GCC release can be obtained from SVN
> svn co svn://gcc.gnu.org/svn/gcc/tags/gcc_4_1_1_release gcc_4_1_1
> If you don't have SVN search their website for a tarball.
> Obtain the aforementioned versions of newlib and binutils (you'll have
> to search for these
> the gcc website and/or google will get you there pretty quickly) and
> unpack them such
> that you have the following directory layout
>
> ./gcc_4_1_1
> ./gcc_4_1_1/newlib
> ./binutils-2.16
> ./buildall.py
> ./patch
> ./configure.patch
>
> Either apply configure.patch using SVN (and I have no idea how to do
> that from the
> command line version) or apply "patch" using :
> patch gcc_4_1_1/libstdc++-v3/configure -ipatch
>
> Let's assume you want to install to /opt/ecos/gcc411:
> run the attached script as
> python buildall.py /opt/ecos/gcc411
> *
> *see also
> http://gcc.gnu.org/install/
>
> Good luck!*
> *
>>>
>>>> sh-elf/sh-elf/include
>>>> Thread model: single
>>>> gcc version 3.2.1
>>>
>>> We found a bug in this version (probably the same one). I managed to
>>> compile GCC 4.1.1 using the following sources
>>>
>>> binutils 2.16
>>> Newlib 1.14.0 (copy this to inside the GCC source directory)
>>> Gcc 4.1.1
>>>
>>> I had to make one hack to the configure file. It fails on a test,
>>> but you can proceed without it, you'll just have to inspect the file
>>> when the problem occurs and comment out that test. I can't remember
>>> any more details than that sorry.
>>>
>>> binutils is compiled separately. Newlib is not strictly needed by
>>> ecos but I found GCC wouldn't compile without it (use the
>>> --with-newlib option in the configure).
>>>
>>> btw the compile time is measured in hours (about 4.5 on the PC I used)
>>>
>>>
>>> --
>>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>>>
>>>
>>
>
>
--------------------------------------------------------------------------------
> Index: libstdc++-v3/configure
> ===================================================================
> --- libstdc++-v3/configure (revision 114326)
> +++ libstdc++-v3/configure (working copy)
> @@ -4576,6 +4576,8 @@
> ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS
> conftest.$ac_ext $LIBS >&5'
> ac_compiler_gnu=$ac_cv_c_compiler_gnu
>
> +gcc_no_link=yes
> +
> if test x$gcc_no_link = xyes; then
> { { echo "$as_me:$LINENO: error: Link tests are not allowed after
> GCC_NO_EXECUTABLES." >&5
> echo "$as_me: error: Link tests are not allowed after GCC_NO_EXECUTABLES."
> >&2;}
> @@ -87646,6 +87648,8 @@
> fi
> fi
>
> +gcc_no_link=no
> +
> # Check to see if 'gnu' can win.
> if test $enable_symvers = gnu; then
> # Check to see if libgcc_s exists, indicating that shared libgcc is
> possible.
> @@ -87700,6 +87704,7 @@
> echo "$as_me: failed program was:" >&5
> sed 's/^/| /' conftest.$ac_ext >&5
>
> +gcc_no_link=no
> glibcxx_shared_libgcc=no
> fi
> rm -f conftest.err conftest.$ac_objext \
> @@ -88575,6 +88580,8 @@
> echo "${ECHO_T}$glibcxx_cv_func_setenv_use" >&6
> if test x$glibcxx_cv_func_setenv_use = x"yes"; then
>
> +gcc_no_link=no
> +
> for ac_func in setenv
> do
> as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
>
--------------------------------------------------------------------------------
> #!/usr/bin/python
>
> import os
> import sys
>
> def do(cmd):
> err = os.system(cmd)
> if (err != 0):
> sys.exit(err)
>
> if sys.platform != "cygwin":
> print "This script is for a cygwin build environment"
> sys.exit(-1)
>
> try:
> outdir = sys.argv[1]
> except:
> print "Please specify output directory for built toolchain"
> sys.exit(-1)
>
> startdir = os.getcwd()
>
> if True:
> do("mkdir -p /tmp/build/binutils")
> os.chdir("/tmp/build/binutils")
> do("%s/binutils-2.16/configure --target=sh-elf --prefix=%s -v 2>&1 | tee
> binconfig.out" % (startdir, outdir))
> do("make -w all install 2>&1 | tee binmake.out")
>
> #sys.exit(0)
>
> savepath = os.environ["PATH"]
> os.environ["PATH"] = "%s/bin:%s" %(outdir, savepath)
> do("mkdir -p /tmp/build/gcc")
> os.chdir("/tmp/build/gcc")
> do("%s/gcc_4_1_1/configure --target=sh-elf --prefix=%s --enable-languages=c,c++
> --with-gnu-as --with-gnu-ld --with-newlib --with-gxx-include-dir=%s/sh-elf/include
> --with-ecos -v 2>&1 | tee configgcc.txt " %(startdir, outdir, outdir))
> do("make -w all install 2>&1 | tee makegcc.txt")
>
>
>
--------------------------------------------------------------------------------
> 4578a4579,4580
>> gcc_no_link=yes
>>
> 87648a87651,87652
>> gcc_no_link=no
>>
> 87702a87707
>> gcc_no_link=no
> 88577a88583,88584
>> gcc_no_link=no
>>
>
>
--------------------------------------------------------------------------------
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: Wrongfully compiled code
2008-01-18 12:16 ` Dave Lawrence
2008-01-18 14:40 ` Gregg Levine
2008-01-21 0:34 ` ariga masahiro
@ 2008-02-04 1:49 ` ariga masahiro
2008-02-04 11:38 ` Dave Lawrence
2 siblings, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-02-04 1:49 UTC (permalink / raw)
To: Dave Lawrence; +Cc: ecos-discuss
Hello Dave and others,
To Mr.Dave Lawrence,
I have studied a little bit about building sh-elf-gcc.
As I know nothing about Python,I made my shell scripts from it.
I append contents of these shell scripts below.
I could not find out what configure.patch is and how to do it,
so I did not do anything about it.
Perhaps this is the cause of trouble but I explain later.
I decided the directory to hold newly built files to be
/usr/local/sh-elf/bin.
I downloaded next sources into /usr/local/sh-elf
and decompressed them.
binutils-2.16.tar.bz2
gcc-4.1.1.tar.bz2
newlib-1.14.0.tar.gz
After that newly directory looks like below.
/usr
`-- local
`-- sh-elf
|-- binutils-2.16
|-- newlib-1.14.0
|-- gcc-4.1.1
|-- bin
|
And I made building-directories in which I executed building scripts.
/tmp/build/build_binutils
/tmp/build/build_gcc
I made setup.sh to set environment variables like TARGET,PREFIX etc.
First of all I built binutils
and this succeeded without any trouble.
$ cd /tmp/build
$ . setup.sh
$ cd build_binutils
$ . binutilsbuild.sh
And I executed appendpath.sh which set PATH to /usr/local/sh-elf/bin.
$ cd ..
$ . appendpath.sh
And I tried to build gcc.
Before that,I made symbolic link to newlib like next.
$ cd /usr/local/sh-elf/gcc-4.1.1
$ ln -s ../newlib-1.14.0/newlib ../newlib-1.14.0/libgloss
../newlib-1.14.0/COPYING.NEWLIB .
Then I executed buildgcconetime.sh
$ cd /tmp/build/build_gcc
$ . buildgcconetime.sh
but I was encountered next error.
checking for ISO C99 support in <stdio.h>... yes
checking for ISO C99 support in <stdlib.h>... no
checking for ISO C99 support in <wchar.h>... no
checking for fully enabled ISO C99 support... no
configure: Debug build flags set to -g3 -O0
checking for additional debug build... no
checking for extra compiler flags for building...
checking for thread model used by GCC... single
checking for shared libgcc... configure: error: Link tests are not allowed
after
GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/tmp/build/build_gcc'
make: *** [all] Error 2
make: Leaving directory `/tmp/build/build_gcc'
My first-guess was that since this includes "test" ,
I remembered Dave's next sentences.
"I had to make one hack to the configure file. It fails on a test, but
you can proceed without it, you'll just have to inspect the file when
the problem occurs and comment out that test. I can't remember any more
details than that sorry."
Now is this related to what you mean ?
If it does,could you elaborate what it is and how I should do it ?
Like which file I should apply configure.patch to,and how ?
Or is it not related to what you mean ?
Anyway would you please help me ?
There is one more thing I care about.
Cygwin's original gnutools exec file directory is next.
/cygwin/opt/ecos/gnutools/sh-elf/bin
I noticed when I build it is interfered with.
First I renamed this directory like /gnutools-old
but I was encountered error like next.
echo 'STMP_FIXPROTO=""' \
>>
/usr/local/sh-elf/lib/gcc/sh-elf/4.1-GNUSH_v0602/install-tool
s/mkheaders.conf
echo 'STMP_FIXINC="stmp-fixinc"' \
>>
/usr/local/sh-elf/lib/gcc/sh-elf/4.1-GNUSH_v0602/install-tool
s/mkheaders.conf
make[1]: *** No rule to make target
`/opt/ecos/gnutools/sh-elf/bin/sh-elf-ld', n
eeded by `stamp-collect-ld'. Stop.
make[1]: Leaving directory `/home/tkernel/shtools/buildshgcc/build_gcc/gcc'
make: *** [install-gcc] Error 2
So I remained it as it was and only renamed next exec files.
sh-elf-as.exe.prev
sh-elf-gcc.exe.prev
I am not sure if I am right about it.
If I succeeded to build newly sh-elf-gcc in /usr/local/sh-elf/bin
I intend to overwrite exec files in /usr/local/sh-elf/bin to
/opt/ecos/gnutools/sh-elf/bin.
Am I right ?
Would you please enlighten me ?
I am much obliged to you.
shell scripts
=========================================================
setup.sh ;this is for setting environment variables like next.
export TARGET=sh-elf
export HOST=i686-pc-cygwin
export BUILD=i686-pc-cygwin
export PREFIX=/usr/local/sh-elf
export CFLAGS="-O2"
export CXXFLAGS="-O2"
export CFLAGS_FOR_TARGET="-Os"
export CXXFLAGS_FOR_TARGET="Os"
--------------------------------------------------------
appendpath.sh ;this is for adding newly built exec Directory to PATH
PATH=$PATH:/usr/local/sh-elf/bin
--------------------------------------------------------
binutilsbuild.sh ;this is script for building binutils.
/usr/local/sh-elf/binutils-2.16/configure --target=$TARGET --host=$HOST --build=$BUILD
--prefix=$PREFIX 2>&1 | tee config.out
make 2>&1 | tee makeall.out
make install 2>&1 | tee makeinstall.out
--------------------------------------------------------
buildgcconetime.sh ;this is script for building sh-elf-gcc
/usr/local/sh-elf/gcc-4.1.1/configure --target=$TARGET --host=$HOST --build=$BUILD
--prefix=$PREFIX --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib
--with-ggxx-include-dir=/usr/local/sh-elf/sh-elf/include --with-ecos -v
2>&1 | tee configgcc.txt
make -w all install 2>&1 | tee makegcc.txt
Masahiro Ariga
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* [ECOS] Re: Wrongfully compiled code
2008-02-04 1:49 ` ariga masahiro
@ 2008-02-04 11:38 ` Dave Lawrence
2008-02-12 1:06 ` ariga masahiro
0 siblings, 1 reply; 41+ messages in thread
From: Dave Lawrence @ 2008-02-04 11:38 UTC (permalink / raw)
To: ecos-discuss
ariga masahiro wrote:
> Hello Dave and others,
>
> To Mr.Dave Lawrence,
> I have studied a little bit about building sh-elf-gcc.
> As I know nothing about Python,I made my shell scripts from it.
> I append contents of these shell scripts below.
> I could not find out what configure.patch is and how to do it,
> so I did not do anything about it.
> Perhaps this is the cause of trouble but I explain later.
>
> I decided the directory to hold newly built files to be
> /usr/local/sh-elf/bin.
>
> I downloaded next sources into /usr/local/sh-elf
> and decompressed them.
>
> binutils-2.16.tar.bz2
> gcc-4.1.1.tar.bz2
> newlib-1.14.0.tar.gz
>
> After that newly directory looks like below.
> /usr
> `-- local
> `-- sh-elf
> |-- binutils-2.16
> |-- newlib-1.14.0
> |-- gcc-4.1.1
> |-- bin
> |
>
> And I made building-directories in which I executed building scripts.
> /tmp/build/build_binutils
> /tmp/build/build_gcc
>
> I made setup.sh to set environment variables like TARGET,PREFIX etc.
>
> First of all I built binutils
> and this succeeded without any trouble.
>
> $ cd /tmp/build
> $ . setup.sh
> $ cd build_binutils
> $ . binutilsbuild.sh
>
> And I executed appendpath.sh which set PATH to /usr/local/sh-elf/bin.
>
> $ cd ..
> $ . appendpath.sh
>
> And I tried to build gcc.
> Before that,I made symbolic link to newlib like next.
>
> $ cd /usr/local/sh-elf/gcc-4.1.1
> $ ln -s ../newlib-1.14.0/newlib ../newlib-1.14.0/libgloss
> ../newlib-1.14.0/COPYING.NEWLIB .
>
> Then I executed buildgcconetime.sh
>
> $ cd /tmp/build/build_gcc
> $ . buildgcconetime.sh
>
> but I was encountered next error.
>
> checking for ISO C99 support in <stdio.h>... yes
> checking for ISO C99 support in <stdlib.h>... no
> checking for ISO C99 support in <wchar.h>... no
> checking for fully enabled ISO C99 support... no
> configure: Debug build flags set to -g3 -O0
> checking for additional debug build... no
> checking for extra compiler flags for building...
> checking for thread model used by GCC... single
> checking for shared libgcc... configure: error: Link tests are not
> allowed after
> GCC_NO_EXECUTABLES.
> make[1]: *** [configure-target-libstdc++-v3] Error 1
> make[1]: Leaving directory `/tmp/build/build_gcc'
> make: *** [all] Error 2
> make: Leaving directory `/tmp/build/build_gcc'
>
> My first-guess was that since this includes "test" ,
> I remembered Dave's next sentences.
>
> "I had to make one hack to the configure file. It fails on a test, but
> you can proceed without it, you'll just have to inspect the file when
> the problem occurs and comment out that test. I can't remember any more
> details than that sorry."
>
> Now is this related to what you mean ?
> If it does,could you elaborate what it is and how I should do it ?
> Like which file I should apply configure.patch to,and how ?
>
Yes this was the error I had. I attached two files "patch" and
"configure.patch" which was a bit pointless as you only need one of
them. "patch" was created using "diff" from the Cygwin command line and
can be applied using "patch" (the program). So the command you need is
patch gcc-4.1.1/libstdc++-v3/configure patch
(where the first use of the word patch is the program name and the
second use is the name of the file)
> Or is it not related to what you mean ?
> Anyway would you please help me ?
>
> There is one more thing I care about.
>
> Cygwin's original gnutools exec file directory is next.
> /cygwin/opt/ecos/gnutools/sh-elf/bin
>
> I noticed when I build it is interfered with.
> First I renamed this directory like /gnutools-old
> but I was encountered error like next.
>
> echo 'STMP_FIXPROTO=""' \
> >>
> /usr/local/sh-elf/lib/gcc/sh-elf/4.1-GNUSH_v0602/install-tool
> s/mkheaders.conf
> echo 'STMP_FIXINC="stmp-fixinc"' \
> >>
> /usr/local/sh-elf/lib/gcc/sh-elf/4.1-GNUSH_v0602/install-tool
> s/mkheaders.conf
> make[1]: *** No rule to make target
> `/opt/ecos/gnutools/sh-elf/bin/sh-elf-ld', n
> eeded by `stamp-collect-ld'. Stop.
> make[1]: Leaving directory `/home/tkernel/shtools/buildshgcc/build_gcc/gcc'
> make: *** [install-gcc] Error 2
>
> So I remained it as it was and only renamed next exec files.
> sh-elf-as.exe.prev
> sh-elf-gcc.exe.prev
>
> I am not sure if I am right about it.
>
> If I succeeded to build newly sh-elf-gcc in /usr/local/sh-elf/bin
> I intend to overwrite exec files in /usr/local/sh-elf/bin to
> /opt/ecos/gnutools/sh-elf/bin.
> Am I right ?
The fact that its trying to drag in files from your old install doesn't
sound good - I'd go with your plan of renaming that to gnutools-old or
something. The "no rule to make target ..." error is almost certainly
caused by dependency file generated during your previous build - try
doing a "make clean" and start again.
>
> Would you please enlighten me ?
> I am much obliged to you.
>
> shell scripts
> =========================================================
> setup.sh ;this is for setting environment variables like next.
> export TARGET=sh-elf
> export HOST=i686-pc-cygwin
> export BUILD=i686-pc-cygwin
> export PREFIX=/usr/local/sh-elf
> export CFLAGS="-O2"
> export CXXFLAGS="-O2"
> export CFLAGS_FOR_TARGET="-Os"
> export CXXFLAGS_FOR_TARGET="Os"
> --------------------------------------------------------
> appendpath.sh ;this is for adding newly built exec Directory to PATH
> PATH=$PATH:/usr/local/sh-elf/bin
> --------------------------------------------------------
> binutilsbuild.sh ;this is script for building binutils.
> /usr/local/sh-elf/binutils-2.16/configure --target=$TARGET --host=$HOST
> --build=$BUILD --prefix=$PREFIX 2>&1 | tee config.out
> make 2>&1 | tee makeall.out
> make install 2>&1 | tee makeinstall.out
> --------------------------------------------------------
> buildgcconetime.sh ;this is script for building sh-elf-gcc
> /usr/local/sh-elf/gcc-4.1.1/configure --target=$TARGET --host=$HOST
> --build=$BUILD --prefix=$PREFIX --enable-languages=c,c++ --with-gnu-as
> --with-gnu-ld --with-newlib
> --with-ggxx-include-dir=/usr/local/sh-elf/sh-elf/include --with-ecos -v
> 2>&1 | tee configgcc.txt
> make -w all install 2>&1 | tee makegcc.txt
>
> Masahiro Ariga
>
>
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: Wrongfully compiled code
2008-02-04 11:38 ` Dave Lawrence
@ 2008-02-12 1:06 ` ariga masahiro
2008-02-12 10:55 ` Dave Lawrence
0 siblings, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-02-12 1:06 UTC (permalink / raw)
To: ecos-discuss, Dave Lawrence
[-- Attachment #1: Type: text/plain, Size: 6110 bytes --]
Hello,Dave,and others,
Thanks to you,
as I applied patch that you taught me,I cleared next error.
> checking for shared libgcc... configure: error: Link tests are not
I exulted and expected to succeed,but lastly(I hope)
there happened next error.
checking for C compiler default output file name... configure: error: C
compiler
cannot create executables
See `config.log' for more details.
make[1]: *** [configure-target-libssp] Error 1
make[1]: Leaving directory `/tmp/build/build_gcc'
make: *** [all] Error 2
make: Leaving directory `/tmp/build/build_gcc'
I searched among many config.logs and found that
\tmp\build\build_gcc\sh-elf\m2a\libssp\config.log
contained above error message.
It says,
configure:2274: $? = 0
configure:2276:
/tmp/build/build_gcc/./gcc/xgcc -B/tmp/build/build_gcc/./gcc/ -nostdinc -B/tmp/build/build_gcc/sh-elf/m2a/newlib/
-isystem /tmp/build/build_gcc/sh-elf/m2a/newlib/targ-include -isystem
/usr/local/sh-elf/gcc-4.1.1/newlib/libc/include -B/usr/local/sh-elf/sh-elf/bin/
-B/usr/local/sh-elf/sh-elf/lib/ -isystem
/usr/local/sh-elf/sh-elf/include -isystem
/usr/local/sh-elf/sh-elf/sys-include -m2a -v </dev/null >&5
Reading specs from /tmp/build/build_gcc/./gcc/specs
Target: sh-elf
Configured with:
/usr/local/sh-elf/gcc-4.1.1/configure --target=sh-elf --host=i686-pc-cygwin
--build=i686-pc-cygwin --prefix=/usr/local/sh-elf --enable-languages=c,c++ --with-gnu-as
--with-gnu-ld --with-newlib --with-ggxx-include-dir=/usr/local/sh-elf/sh-elf/include
--with-ecos -v : (reconfigured)
/usr/local/sh-elf/gcc-4.1.1/configure --target=sh-elf --host=i686-pc-cygwin
--build=i686-pc-cygwin --prefix=/usr/local/sh-elf --enable-languages=c,c++ --with-gnu-as
--with-gnu-ld --with-newlib --with-ggxx-include-dir=/usr/local/sh-elf/sh-elf/include
--with-ecos -v : (reconfigured)
/usr/local/sh-elf/gcc-4.1.1/configure --target=sh-elf --host=i686-pc-cygwin
--build=i686-pc-cygwin --prefix=/usr/local/sh-elf --enable-languages=c,c++ --with-gnu-as
--with-gnu-ld --with-newlib --with-ggxx-include-dir=/usr/local/sh-elf/sh-elf/include
--with-ecos -v : (reconfigured)
/usr/local/sh-elf/gcc-4.1.1/configure --target=sh-elf --host=i686-pc-cygwin
--build=i686-pc-cygwin --prefix=/usr/local/sh-elf --enable-languages=c,c++ --with-gnu-as
--with-gnu-ld --with-newlib --with-ggxx-include-dir=/usr/local/sh-elf/sh-elf/include
--with-ecos -v : (reconfigured)
/usr/local/sh-elf/gcc-4.1.1/configure --target=sh-elf --prefix=/usr/local/sh-elf
--enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-ggxx-include-dir=/usr/local/sh-elf/sh-elf/include
--with-ecos -v : (reconfigured)
/usr/local/sh-elf/gcc-4.1.1/configure --target=sh-elf --prefix=/usr/local/sh-elf
--enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-ggxx-include-dir=/usr/local/sh-elf/sh-elf/include
--with-ecos -v
Thread model: single
gcc version 4.1.1
configure:2279: $? = 0
configure:2281:
/tmp/build/build_gcc/./gcc/xgcc -B/tmp/build/build_gcc/./gcc/ -nostdinc -B/tmp/build/build_gcc/sh-elf/m2a/newlib/
-isystem /tmp/build/build_gcc/sh-elf/m2a/newlib/targ-include -isystem
/usr/local/sh-elf/gcc-4.1.1/newlib/libc/include -B/usr/local/sh-elf/sh-elf/bin/
-B/usr/local/sh-elf/sh-elf/lib/ -isystem
/usr/local/sh-elf/sh-elf/include -isystem
/usr/local/sh-elf/sh-elf/sys-include -m2a -V </dev/null >&5
xgcc: '-V' must come at the start of the command line
configure:2284: $? = 1
configure:2307: checking for C compiler default output file name
configure:2310:
/tmp/build/build_gcc/./gcc/xgcc -B/tmp/build/build_gcc/./gcc/ -nostdinc -B/tmp/build/build_gcc/sh-elf/m2a/newlib/
-isystem /tmp/build/build_gcc/sh-elf/m2a/newlib/targ-include -isystem
/usr/local/sh-elf/gcc-4.1.1/newlib/libc/include -B/usr/local/sh-elf/sh-elf/bin/
-B/usr/local/sh-elf/sh-elf/lib/ -isystem
/usr/local/sh-elf/sh-elf/include -isystem
/usr/local/sh-elf/sh-elf/sys-include -m2a -O2 -O2 conftest.c >&5
/tmp/build/build_gcc/sh-elf/m2a/newlib/libc.a: could not read symbols:
Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
configure:2313: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "libssp"
| #define PACKAGE_TARNAME "libssp"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "libssp 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "libssp"
| #define VERSION "1.0"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2352: error: C compiler cannot create executables
See `config.log' for more details.
I also noticed other config.logs relating to each libssp directories
contained error messages like next.
---
conftest.c:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'me'
configure:2749: $? = 1
configure: failed program was:
| #ifndef __cplusplus
| choke me
| #endif
configure:2893: checking for style of include used by make
conftest.c:11:28: error: ac_nonexistent.h: No such file or directory
configure:3256: $? = 1
configure: failed program was:
| /* confdefs.h. */
---
I do not know why it happened,and what I should do,
would you please help me ?
I append the same config.log and build logs "configgcc.txt","makegcc.txt" in
tar.bz2 format.
Below are my shell scripts.
===============================================
[setup.sh]
export TARGET=sh-elf
export PREFIX=/usr/local/sh-elf
export CFLAGS="-O2"
export CXXFLAGS="-O2"
export CFLAGS_FOR_TARGET="-Os"
export CXXFLAGS_FOR_TARGET="Os"
===============================================
[appendpath.sh]
PATH=$PATH:/usr/local/sh-elf/bin
===============================================
I separated building shell script.
[buildgcc-1.sh]
/usr/local/sh-elf/gcc-4.1.1/configure --target=$TARGET --prefix=$PREFIX --enable-languages=c,c++
--with-gnu-as --with-gnu-ld --with-newlib --with-ggxx-include-dir=/usr/local/sh-elf/sh-elf/include
--with-ecos -v 2>&1 | tee configgcc.txt
[buildgcc-2.sh]
make clean
make -w all install 2>&1 | tee makegcc.txt
===============================================
I am very much obliged to your help.
Thank you in advance.
Masahiro Ariga
[-- Attachment #2: log_files.tar.bz2 --]
[-- Type: application/octet-stream, Size: 51368 bytes --]
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* [ECOS] Re: Wrongfully compiled code
2008-02-12 1:06 ` ariga masahiro
@ 2008-02-12 10:55 ` Dave Lawrence
0 siblings, 0 replies; 41+ messages in thread
From: Dave Lawrence @ 2008-02-12 10:55 UTC (permalink / raw)
To: ecos-discuss
ariga masahiro wrote:
> Hello,Dave,and others,
>
> Thanks to you,
> as I applied patch that you taught me,I cleared next error.
>> checking for shared libgcc... configure: error: Link tests are not
>
> I exulted and expected to succeed,but lastly(I hope)
> there happened next error.
>
> checking for C compiler default output file name... configure: error: C
> compiler
> cannot create executables
Don't know, I've not had this issue. I assume the c compiler you are
using is the native Cygwin GCC? Maybe try compiling hello world with it
to determine whether it really cannot create executables.
Maybe someone on the GCC cross-compiling mailing list can help you:
Newsgroup gmane.comp.gcc.cross-compiling
e-mail crossgcc@sourceware.org
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* [ECOS] How to re-install newly compiled gnutools
2008-01-08 0:05 ` Gary Thomas
2008-01-08 1:05 ` ariga masahiro
@ 2008-02-22 4:57 ` ariga masahiro
2008-02-22 7:15 ` ariga masahiro
1 sibling, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-02-22 4:57 UTC (permalink / raw)
To: ecos-discuss
[-- Attachment #1: Type: text/plain, Size: 3294 bytes --]
Hello everyone,
I have made sh-elf-gcc version 4.1.1 from gcc4.1.1.
I used two ways to make it.
After made them,I tried to run eCos configure.exe using them.
One was resulted in no problem other was resulted in error.
Although one was looked succeeded I am dubious about it's reliability.
So please enlighten me which do you think is the better one.
I decided the directory to hold newly built files to be
/usr/local/sh-elf/bin.
I downloaded next sources into /usr/local/sh-elf
and decompressed them.
binutils-2.16.tar.bz2
gcc-4.1.1.tar.bz2
newlib-1.14.0.tar.gz
And I made building-directories in which I executed building scripts.
/tmp/build/build_binutils
/tmp/build/build_gcc
The point is that Cygwin's original gnutools exec files' directory is next.
/cygwin/opt/ecos/gnutools/sh-elf/bin
I noticed when I build it is interfered with.
I must have found the way to avoid it.
Since I did not know correct way to do with it,
I concocted two ways to pass compiling through.
(1)
I remained original gnutools exec files' directory as it is,
but only renamed next two exe files in /opt/ecos/gnutools/sh-elf/bin.
sh-elf-as.exe.prev
sh-elf-gcc.exe.prev
After compiled, newly sh-elf-as.exe, sh-elf-gcc.exe and others were
generated in
\cygwin\usr\local\sh-elf\bin
I tried to run eCos configure.exe and tried to build
without any changing of PATH.
It appeared to succeed.It used sh-elf-gcc.
I appended eCos configure.exe building logs,in both cases of success and
failure.
Please refer to success one.
(2)
I felt anxiety that changing only two files is not enough.
So I renamed gnutools directory to gnutools-old.
And I executed building scripts,
but I was encountered error like next.
echo 'STMP_FIXINC="stmp-fixinc"' >>
/usr/local/sh-elf/lib/gcc/sh-elf/4.1-GNUSH_v0602/install-tool
s/mkheaders.conf
make[1]: *** No rule to make target
`/opt/ecos/gnutools/sh-elf/bin/sh-elf-ld', n
eeded by `stamp-collect-ld'. Stop.
make[1]: Leaving directory `/home/tkernel/shtools/buildshgcc/build_gcc/gcc'
make: *** [install-gcc] Error 2
I discovered in
C:\cygwin\tmp\build\build_gcc\gcc\Makefile
next odd lines.
ORIGINAL_LD_FOR_TARGET = /opt/ecos/gnutools/sh-elf/bin/sh-elf-ld
ORIGINAL_NM_FOR_TARGET = /opt/ecos/gnutools/sh-elf/bin/sh-elf-nm
I thought these should not be /opt/ecos/gnutools/
but point to newly directory /usr/local/sh-elf/.
So I changed these lines to next.
ORIGINAL_LD_FOR_TARGET = /usr/local/sh-elf/bin/sh-elf-ld
ORIGINAL_NM_FOR_TARGET = /usr/local/sh-elf/bin/sh-elf-nm
And I executed script to do only "make" like next.
make clean
make -w all install 2>&1 | tee makegcc.txt
After succeeded to compile,I made empty /opt/ecos/gnutools
and copied /usr/local/sh-elf under it.
I thought this way is more reliable than first one.
When I tried to run ecos configure.exe it apparently became slow to run.
And appeared warning of something like changing configuration.
Nevertheless I selected target and net and clicked "Library"
and then encountered error.
Please refer to failure log I appended.
Even (1) looked successful I am not sure I could use it.
Do you think it is reliable enough to use it for ecos configure.exe ?
Or if (2) is better reliable,please teach me the cause of error.
I am much obliged to your kindness.
Thank you in advance.
Masahiro Ariga
[-- Attachment #2: config-buid-logs.tar.gz --]
[-- Type: application/x-gzip, Size: 18204 bytes --]
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] How to re-install newly compiled gnutools
2008-02-22 4:57 ` [ECOS] How to re-install newly compiled gnutools ariga masahiro
@ 2008-02-22 7:15 ` ariga masahiro
2008-05-16 8:13 ` [ECOS] When or on what condition does "deschedule" happen? ariga masahiro
0 siblings, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-02-22 7:15 UTC (permalink / raw)
To: ecos-discuss
Hello everyone,
I am sorry to sending two mails at one time.
But I am encountered next phenomoinon,
and I think it is concerned with my first inqury mail,
So I mail this as a postscript.
Correct or not, I procceede to configure-build
using /usr/local/sh-elf/ installed by (1) way.
Of course I added /usr/local/sh-elf/bin to PATH and
remained gnutools directory as it is.
As I said I succeeded configure-build using target and "net"
and made libextras.a.
But when I tried to link application program,(I append Makefile below)
I was encountered next error.
-- error log
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/sys/net/route.c:731:
unde
fined reference to `_cyg_panic'
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/sys/net/route.c:731:
unde
fined reference to `_cyg_net_malloc'
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/sys/net/route.c:731:
unde
fined reference to `_cyg_net_free'
/ecos-c/cygwin/home/LINK/ecoscvs_l_net_20080221-sh-elf-gcc4.1.1/untitled1_instal
l/lib/libtarget.a(net_bsd_tcpip_route.o): In function `cyg_rt_setgate':
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/sys/net/route.c:1016:
und
efined reference to `_cyg_net_malloc'
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/sys/net/route.c:1016:
und
efined reference to `_cyg_net_free'
/ecos-c/cygwin/home/LINK/ecoscvs_l_net_20080221-sh-elf-gcc4.1.1/untitled1_instal
l/lib/libtarget.a(net_bsd_tcpip_route.o): In function `cyg_route_init':
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/sys/net/route.c:105:
unde
fined reference to `_cyg_rn_init'
/ecos-c/cygwin/home/LINK/ecoscvs_l_net_20080221-sh-elf-gcc4.1.1/untitled1_instal
l/lib/libtarget.a(net_bsd_tcpip_uipc_domain.o): In function `pffasttimo':
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/sys/kern/uipc_domain.c:27
7: undefined reference to `_cyg_hz'
/ecos-c/cygwin/home/LINK/ecoscvs_l_net_20080221-sh-elf-gcc4.1.1/untitled1_instal
l/lib/libtarget.a(net_bsd_tcpip_uipc_domain.o): In function `pfslowtimo':
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/sys/kern/uipc_domain.c:26
3: undefined reference to `_cyg_hz'
/ecos-c/cygwin/home/LINK/ecoscvs_l_net_20080221-sh-elf-gcc4.1.1/untitled1_instal
l/lib/libtarget.a(net_bsd_tcpip_uipc_domain.o): In function `domaininit':
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/sys/kern/uipc_domain.c:16
1: undefined reference to `_zinit'
/ecos-c/cygwin/home/LINK/ecoscvs_l_net_20080221-sh-elf-gcc4.1.1/untitled1_instal
l/lib/libtarget.a(net_bsd_tcpip_uipc_socket.o): In function
`cyg_sooptcopyout':
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/sys/kern/uipc_socket.c:12
68: undefined reference to `_cyg_copyout'
-- sorry I omit intermediate part. too many "undefined reference to"
occurred. --
/opt/ecoscvs_l/ecos/packages/net/common/current/src/bootp_support.c:611:
undefin
ed reference to `_setdomainname'
/opt/ecoscvs_l/ecos/packages/net/common/current/src/bootp_support.c:611:
undefin
ed reference to `_cyg_dns_res_init'
/ecos-c/cygwin/home/LINK/ecoscvs_l_net_20080221-sh-elf-gcc4.1.1/untitled1_instal
l/lib/libtarget.a(net_bsd_tcpip_timeout.o): In function `cyg_callout_reset':
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/ecos/timeout.c:414:
undef
ined reference to `_cyg_current_time'
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/ecos/timeout.c:414:
undef
ined reference to `_cyg_alarm_initialize'
/opt/ecoscvs_l/ecos/packages/net/bsd_tcpip/current/src/ecos/timeout.c:427:
undef
ined reference to `_diag_printf'
collect2: ld returned 1 exit status
make: *** [nc_test_slave] Error 1
Next is my application's Makefile
=======================================
export PREFIX :=
/ecos-c/cygwin/home/LINK/ecoscvs_l_net_20080221-sh-elf-gcc4.1.1/untitled1_install
export COMMAND_PREFIX := sh-elf-
export CC := $(COMMAND_PREFIX)gcc
export OBJCOPY := $(COMMAND_PREFIX)objcopy
export HOST := CYGWIN
export AR := $(COMMAND_PREFIX)ar
XCC = sh-elf-gcc
## Build flags.
CFLAGS = -g -Wall -I$(PREFIX)/include -ffunction-sections -fdata-sections
LDFLAGS
= -nostartfiles -L$(PREFIX)/lib -Wl,--gc-sections -Wl,--Map -Wl,nc_test_slave.map
LIBS = -Ttarget.ld -nostdlib
LD = $(XCC)
## Build rules.
all: nc_test_slave
nc_test_slave.o: nc_test_slave.c
$(XCC) -c -o $*.o $(CFLAGS) $<
nc_test_slave: nc_test_slave.o
$(LD) $(LDFLAGS) -o $@ $@.o $(LIBS)
clean:
-rm -f nc_test_slave.exe nc_test_slave.o nc_test_slave.map
============================ end of Makefile
Please help me.
Masahiro Ariga
next is my last mail.
=========================
> Hello everyone,
>
> I have made sh-elf-gcc version 4.1.1 from gcc4.1.1.
> I used two ways to make it.
> After made them,I tried to run eCos configure.exe using them.
> One was resulted in no problem other was resulted in error.
> Although one was looked succeeded I am dubious about it's reliability.
> So please enlighten me which do you think is the better one.
>
> I decided the directory to hold newly built files to be
> /usr/local/sh-elf/bin.
>
> I downloaded next sources into /usr/local/sh-elf
> and decompressed them.
> binutils-2.16.tar.bz2
> gcc-4.1.1.tar.bz2
> newlib-1.14.0.tar.gz
>
> And I made building-directories in which I executed building scripts.
> /tmp/build/build_binutils
> /tmp/build/build_gcc
>
> The point is that Cygwin's original gnutools exec files' directory is
> next.
> /cygwin/opt/ecos/gnutools/sh-elf/bin
>
> I noticed when I build it is interfered with.
> I must have found the way to avoid it.
> Since I did not know correct way to do with it,
> I concocted two ways to pass compiling through.
>
> (1)
> I remained original gnutools exec files' directory as it is,
> but only renamed next two exe files in /opt/ecos/gnutools/sh-elf/bin.
> sh-elf-as.exe.prev
> sh-elf-gcc.exe.prev
>
> After compiled, newly sh-elf-as.exe, sh-elf-gcc.exe and others were
> generated in
> \cygwin\usr\local\sh-elf\bin
>
> I tried to run eCos configure.exe and tried to build
> without any changing of PATH.
> It appeared to succeed.It used sh-elf-gcc.
>
> I appended eCos configure.exe building logs,in both cases of success and
> failure.
> Please refer to success one.
>
> (2)
> I felt anxiety that changing only two files is not enough.
> So I renamed gnutools directory to gnutools-old.
> And I executed building scripts,
> but I was encountered error like next.
>
> echo 'STMP_FIXINC="stmp-fixinc"' >>
> /usr/local/sh-elf/lib/gcc/sh-elf/4.1-GNUSH_v0602/install-tool
> s/mkheaders.conf
> make[1]: *** No rule to make target
> `/opt/ecos/gnutools/sh-elf/bin/sh-elf-ld', n
> eeded by `stamp-collect-ld'. Stop.
> make[1]: Leaving directory
> `/home/tkernel/shtools/buildshgcc/build_gcc/gcc'
> make: *** [install-gcc] Error 2
>
> I discovered in
> C:\cygwin\tmp\build\build_gcc\gcc\Makefile
> next odd lines.
>
> ORIGINAL_LD_FOR_TARGET = /opt/ecos/gnutools/sh-elf/bin/sh-elf-ld
> ORIGINAL_NM_FOR_TARGET = /opt/ecos/gnutools/sh-elf/bin/sh-elf-nm
>
> I thought these should not be /opt/ecos/gnutools/
> but point to newly directory /usr/local/sh-elf/.
> So I changed these lines to next.
>
> ORIGINAL_LD_FOR_TARGET = /usr/local/sh-elf/bin/sh-elf-ld
> ORIGINAL_NM_FOR_TARGET = /usr/local/sh-elf/bin/sh-elf-nm
>
> And I executed script to do only "make" like next.
> make clean
> make -w all install 2>&1 | tee makegcc.txt
>
> After succeeded to compile,I made empty /opt/ecos/gnutools
> and copied /usr/local/sh-elf under it.
> I thought this way is more reliable than first one.
> When I tried to run ecos configure.exe it apparently became slow to run.
> And appeared warning of something like changing configuration.
> Nevertheless I selected target and net and clicked "Library"
> and then encountered error.
> Please refer to failure log I appended.
>
> Even (1) looked successful I am not sure I could use it.
> Do you think it is reliable enough to use it for ecos configure.exe ?
>
> Or if (2) is better reliable,please teach me the cause of error.
> I am much obliged to your kindness.
> Thank you in advance.
>
> Masahiro Ariga
>
>
--------------------------------------------------------------------------------
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* [ECOS] When or on what condition does "deschedule" happen?
2008-02-22 7:15 ` ariga masahiro
@ 2008-05-16 8:13 ` ariga masahiro
2008-05-16 15:26 ` Andrew Lunn
0 siblings, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-05-16 8:13 UTC (permalink / raw)
To: ecos-discuss
Hello everyone,
Please teach me about eCos Thread Scheduler.
When or on what condition does "deschedule" happen ?
Masahiro Ariga
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] When or on what condition does "deschedule" happen?
2008-05-16 8:13 ` [ECOS] When or on what condition does "deschedule" happen? ariga masahiro
@ 2008-05-16 15:26 ` Andrew Lunn
2008-05-19 5:32 ` ariga masahiro
0 siblings, 1 reply; 41+ messages in thread
From: Andrew Lunn @ 2008-05-16 15:26 UTC (permalink / raw)
To: ariga masahiro; +Cc: ecos-discuss
On Fri, May 16, 2008 at 05:12:30PM +0900, ariga masahiro wrote:
> Hello everyone,
>
> Please teach me about eCos Thread Scheduler.
> When or on what condition does "deschedule" happen ?
When the thread blocks.
When a higher priority thread becomes runnable.
When a thread uses up its time slice and there is another thread of
the same priority which is runnable.
When a thread calls yield and there is another thread of the same
priority which is runnable.
When a thread exits.
There is nothing unusual here. Any good book on operating systems will
teach you the same.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] When or on what condition does "deschedule" happen?
2008-05-16 15:26 ` Andrew Lunn
@ 2008-05-19 5:32 ` ariga masahiro
2008-05-19 13:18 ` Andrew Lunn
0 siblings, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-05-19 5:32 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ecos-discuss
Hello everyone,
Thank you,Andrew, for your reply.
There is one unclear point that I would make it clear.
In explaning it ,let me use the scenario that
Anthony J. Massa elaborate in his book
"Embedded Software Development With Ecos".
(supposing since I bought the book I don't infringe its licence)
In case of Multilevel Queue Scheduler,
three threads are created like next.
ThreadC -- priority 30(lower)
ThreadA,B -- priority 0(highest)
- ThreadA - Timeslice - ThreadB -Deschedule - ThreadA -
|
|
Preemption
Deschedule
|
|
ThreadC
ThreadC
Next is Anthony J. Massa's description.
"three threads-Thread A, Thread B, and Thread C-
are configured during creation of the threads at priority levels 0, 0, and
30, respectively.
--- starts with Thread C executing.
Next, Thread A becomes able to run, causing Thread C to be preempted and a
context
switch occurs. During the execution of Thread A, Thread B also becomes able
to run. Thread A
continues until its timeslice period expires. Then, another context switch
occurs allowing Thread
B to run. Thread B completes within its given timeslice period. The
de-scheduling of a thread
can happen for various reasons; for example, by waiting on a mutex that is
not free or delaying
for a specified amount of time. Since Thread A has the highest priority of
tasks waiting to execute,
a context switch occurs and it runs next. After Thread A has completed, a
context switch
takes place allowing Thread C to execute."
My question is last part of Deschedule when ThreadC resumes execution.
Am I correct in assuming that among your conditions, only two conditions
should be fullfiled to make it possible
for ThreadC to resume execution ?
1.When the thread blocks.(How does scheduler recognise this ?)
2.When a thread exits.
If ThreadA does not finish and enter looping state,then isn't there any way
for ThreadC to resume execution ?
Please kindly forgive my ignorance and enlighten me.
Thanks in advance.
Masahiro Ariga
> On Fri, May 16, 2008 at 05:12:30PM +0900, ariga masahiro wrote:
>> Hello everyone,
>>
>> Please teach me about eCos Thread Scheduler.
>> When or on what condition does "deschedule" happen ?
>
> When the thread blocks.
>
> When a higher priority thread becomes runnable.
>
> When a thread uses up its time slice and there is another thread of
> the same priority which is runnable.
>
> When a thread calls yield and there is another thread of the same
> priority which is runnable.
>
> When a thread exits.
>
> There is nothing unusual here. Any good book on operating systems will
> teach you the same.
>
> Andrew
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] When or on what condition does "deschedule" happen?
2008-05-19 5:32 ` ariga masahiro
@ 2008-05-19 13:18 ` Andrew Lunn
2008-05-19 13:31 ` Gary Thomas
2008-05-20 1:26 ` ariga masahiro
0 siblings, 2 replies; 41+ messages in thread
From: Andrew Lunn @ 2008-05-19 13:18 UTC (permalink / raw)
To: ariga masahiro; +Cc: ecos-discuss
> My question is last part of Deschedule when ThreadC resumes execution.
>
> Am I correct in assuming that among your conditions, only two conditions
> should be fullfiled to make it possible
> for ThreadC to resume execution ?
> 1.When the thread blocks.(How does scheduler recognise this ?)
Blocking calls are part of the OS and the scheduler knows about them.
> 2.When a thread exits.
>
> If ThreadA does not finish and enter looping state,then isn't there any
> way for ThreadC to resume execution ?
Nope. The highest priority runnable thread always runs. All high
priority threads need to finish doing what they are doing before a
lower priority threads get to run.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] When or on what condition does "deschedule" happen?
2008-05-19 13:18 ` Andrew Lunn
@ 2008-05-19 13:31 ` Gary Thomas
2008-05-20 1:26 ` ariga masahiro
1 sibling, 0 replies; 41+ messages in thread
From: Gary Thomas @ 2008-05-19 13:31 UTC (permalink / raw)
To: ariga masahiro, ecos-discuss
Andrew Lunn wrote:
>> My question is last part of Deschedule when ThreadC resumes execution.
>>
>> Am I correct in assuming that among your conditions, only two conditions
>> should be fullfiled to make it possible
>> for ThreadC to resume execution ?
>> 1.When the thread blocks.(How does scheduler recognise this ?)
>
> Blocking calls are part of the OS and the scheduler knows about them.
More than that; when a thread blocks, the act of blocking actually
calls into the scheduler to immediately switch to the next available
thread.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] When or on what condition does "deschedule" happen?
2008-05-19 13:18 ` Andrew Lunn
2008-05-19 13:31 ` Gary Thomas
@ 2008-05-20 1:26 ` ariga masahiro
2008-05-20 12:18 ` Andrew Lunn
1 sibling, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-05-20 1:26 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ecos-discuss
Hello everyone,
Thank you very much for your answers.
I've almost got it.
I only need one more affirmation from you.
>> If ThreadA does not finish and enter looping state,then isn't there any
>> way for ThreadC to resume execution ?
>
> Nope. The highest priority runnable thread always runs. All high
> priority threads need to finish doing what they are doing before a
> lower priority threads get to run.
>
Am I correct in thinking that this policy applys also to bitmap scheduler ?
Masahiro Ariga
>> My question is last part of Deschedule when ThreadC resumes execution.
>>
>> Am I correct in assuming that among your conditions, only two conditions
>> should be fullfiled to make it possible
>> for ThreadC to resume execution ?
>> 1.When the thread blocks.(How does scheduler recognise this ?)
>
> Blocking calls are part of the OS and the scheduler knows about them.
>
>> 2.When a thread exits.
>>
>> If ThreadA does not finish and enter looping state,then isn't there any
>> way for ThreadC to resume execution ?
>
> Nope. The highest priority runnable thread always runs. All high
> priority threads need to finish doing what they are doing before a
> lower priority threads get to run.
>
> Andrew
>
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] When or on what condition does "deschedule" happen?
2008-05-20 1:26 ` ariga masahiro
@ 2008-05-20 12:18 ` Andrew Lunn
2008-05-23 7:38 ` ariga masahiro
[not found] ` <000601c8c165$406e0970$1c0110ac@ariga>
0 siblings, 2 replies; 41+ messages in thread
From: Andrew Lunn @ 2008-05-20 12:18 UTC (permalink / raw)
To: ariga masahiro; +Cc: Andrew Lunn, ecos-discuss
>> Nope. The highest priority runnable thread always runs. All high
>> priority threads need to finish doing what they are doing before a
>> lower priority threads get to run.
>>
> Am I correct in thinking that this policy applys also to bitmap scheduler ?
Yes.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] When or on what condition does "deschedule" happen?
2008-05-20 12:18 ` Andrew Lunn
@ 2008-05-23 7:38 ` ariga masahiro
2008-05-23 9:35 ` Nick Garnett
[not found] ` <000601c8c165$406e0970$1c0110ac@ariga>
1 sibling, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-05-23 7:38 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ecos-discuss
Hello,
In order to measure the time of cyg_thread_delay,
I tried to insert next codes at the top of timeslice_main( void )
function in timeslice2 test.
diag_printf("10 SEC Start !3\n");
cyg_thread_delay(1000);
diag_printf("Finisyed !3\n");
But appeared next error.
[cyg_net_init] Init: call_route_init(0x00000000)
[cyg_net_init] Done
10 SEC Start !3
ASSERT FAIL: <1>mlqueue.cxx[286]void
Cyg_Scheduler_Implementation::rem_thread()
Idle thread trying to sleep!
ASSERT FAIL: <1>mlqueue.cxx [ 286] void
Cyg_Scheduler_Implementation::re
m_thread() Idle thread
tryi
ng to sleep!
I searched old mailing list and found next information.
-- below is from old mailing list
Re: Idle Thread trying to sleep - Error Source
On Mon, Jul 31, 2006 at 05:54:59PM +0200, Antoine Arlaud wrote:
> Hi all,
>
>
> My debugger displayed the following error :
> Assert Fail. void Cyg_Scheduler_Implementation::rem_thread(). Idle
> Thread trying to sleep!
>
> What kind of action can be the source of this error ?
>
> Is it because there is potentially somewhere a wait condition on the
> main thread ?
> What else ?
>
> Thanks in advance,
> Regards.
>
> Antoine ARLAUD
Stack overflow is the normal problem. Turn on stack checking or make
the stacks bigger.
Andrew
-- old mailing list end
I would like to increase Stack.
But looks like many Stacks,and I do not know which Stack and how to increase
it.
I am sorry but please teach me how to increase which Stack.
Thanks in advance.
Masahiro Ariga
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] When or on what condition does "deschedule" happen?
2008-05-23 7:38 ` ariga masahiro
@ 2008-05-23 9:35 ` Nick Garnett
0 siblings, 0 replies; 41+ messages in thread
From: Nick Garnett @ 2008-05-23 9:35 UTC (permalink / raw)
To: ariga masahiro; +Cc: Andrew Lunn, ecos-discuss
"ariga masahiro" <ariga@link-lab.co.jp> writes:
> Hello,
>
> In order to measure the time of cyg_thread_delay,
> I tried to insert next codes at the top of timeslice_main( void )
> function in timeslice2 test.
>
> diag_printf("10 SEC Start !3\n");
> cyg_thread_delay(1000);
> diag_printf("Finisyed !3\n");
cyg_thread_delay(), as it's name implies, causes a thread to
delay. timeslice_main() does not run in a thread, it is called
directly from cyg_start().
If you want to run this code, do it in run_tests().
>
> But appeared next error.
> [cyg_net_init] Init: call_route_init(0x00000000)
> [cyg_net_init] Done
Note that you will not get very accurate timings if you have the
network active. The random arrival of broadcast packets from the net
may cause the network threads to run at any time.
--
Nick Garnett eCos Kernel Architect
eCosCentric Limited http://www.eCosCentric.com The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No: 4422071
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* [ECOS] Re: In trouble of timer operations
[not found] ` <000601c8c165$406e0970$1c0110ac@ariga>
@ 2008-05-29 18:23 ` Andrew Lunn
2008-05-30 2:50 ` ariga masahiro
0 siblings, 1 reply; 41+ messages in thread
From: Andrew Lunn @ 2008-05-29 18:23 UTC (permalink / raw)
To: ariga masahiro; +Cc: Andrew Lunn, ecos-discuss
On Thu, May 29, 2008 at 05:23:19PM +0900, ariga masahiro wrote:
> Hello everyone,
>
> In order to certify timer operations I inserted next codes at top of
> run_tests func in timeslice2.c.
The best way to verify the timer operations is to use the given test
programs. clocktruth will tell you if your clock it ticking at the
correct rate.
> My intention is to insert 10msec delay by cyg_thread_delay(1)
> and count timer ticks between using HAL_CLOCK_READ and display difference
> time.
I suggest you first read and understand:
http://ecos.sourceware.org/docs-latest/ref/hal-clocks-and-timers.html
HAL_CLOCK_READ will return the number of hardware ticks since the last
system tick. Since the system tick is by default 10msec, you should
never get HAL_CLOCK_READ return more than 10ms.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: In trouble of timer operations
2008-05-29 18:23 ` [ECOS] Re: In trouble of timer operations Andrew Lunn
@ 2008-05-30 2:50 ` ariga masahiro
2008-05-30 3:09 ` Paul D. DeRocco
0 siblings, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-05-30 2:50 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ecos-discuss
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
Hello Andrew and others,
Thank you Andrew for your reply.
I understand why I can't change CYGNUM_KERNEL_COUNTERS_RTC_PERIOD at my
convenience.
May I ask my second question about cyg_thread_delay(1).
I understand that cyg_thread_delay(1) delays 10msec but my result shows
apparently too short period.
I re-write my test and result.
-- my test
run_tests(CYG_ADDRESS id)
{
|
diag_printf("CYGNUM_KERNEL_COUNTERS_RTC_PERIOD=0x%x\n",CYGNUM_KERNEL_COUNTERS_RTC_PERIOD);
HAL_CLOCK_READ(&thread_ft[0].start);
diag_printf("start=%d\n",thread_ft[0].start);
diag_printf("10msec Start !\n");
cyg_thread_delay(1); //10msec
diag_printf("Finish !\n");
HAL_CLOCK_READ(&thread_ft[0].end);
diag_printf("end=%d\n",thread_ft[0].end);
-- result log
CYGNUM_KERNEL_COUNTERS_RTC_PERIOD=0x12000
start=7103
10msec Start !
Finish !
end=16512
delta=9409
As I said,
My target board is CPU SH7709S,Peripheral clock = 29491200Hz.
I setted CYGHWR_HAL_SH_TMU_PRESCALE_0 = 4 so TMU0's 1tick perid is..
29491200/4=7372800Hz,1/7372800=0.000000135sec=0.135microsec.
On the assumption that HAL_CLOCK_READ operating correctly,
according to result cyg_thread_delay(1) took only
9409 x 0.135 = 1270.215 microsec.
I cannot understand why it finish so short perid.
I re-post untitled.ecc.gz.
Please teach me why I get such result.
Masahiro Ariga
[-- Attachment #2: untitled.ecc.gz --]
[-- Type: application/x-gzip, Size: 89721 bytes --]
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* RE: [ECOS] Re: In trouble of timer operations
2008-05-30 2:50 ` ariga masahiro
@ 2008-05-30 3:09 ` Paul D. DeRocco
2008-05-30 4:11 ` ariga masahiro
0 siblings, 1 reply; 41+ messages in thread
From: Paul D. DeRocco @ 2008-05-30 3:09 UTC (permalink / raw)
To: ecos-discuss
> From: ariga masahiro
>
> I understand that cyg_thread_delay(1) delays 10msec but my result shows
> apparently too short period.
Delays start when you call cyg_thread_delay, and end on a particular timer
interrupt tick. The ticks are 10ms apart, but your call to cyg_thread_delay
isn't synchronized with these ticks. An n-tick delay can therefore range
from n-1 to n ticks in duration.
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: In trouble of timer operations
2008-05-30 3:09 ` Paul D. DeRocco
@ 2008-05-30 4:11 ` ariga masahiro
2008-05-30 4:43 ` Paul D. DeRocco
2008-05-30 6:35 ` Andrew Lunn
0 siblings, 2 replies; 41+ messages in thread
From: ariga masahiro @ 2008-05-30 4:11 UTC (permalink / raw)
To: Paul D. DeRocco, ecos-discuss
Hello Paul and others,
Thank you Paul for your reply.
> Delays start when you call cyg_thread_delay, and end on a particular timer
> interrupt tick. The ticks are 10ms apart, but your call to
> cyg_thread_delay
> isn't synchronized with these ticks. An n-tick delay can therefore range
> from n-1 to n ticks in duration.
Forgive my ignorance,but please teach me more.
If I like to insert exactly, say 20msec, delay how should I write program ?
Thank you in advance.
Masahiro Ariga
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* RE: [ECOS] Re: In trouble of timer operations
2008-05-30 4:11 ` ariga masahiro
@ 2008-05-30 4:43 ` Paul D. DeRocco
2008-05-30 7:26 ` ariga masahiro
2008-05-30 6:35 ` Andrew Lunn
1 sibling, 1 reply; 41+ messages in thread
From: Paul D. DeRocco @ 2008-05-30 4:43 UTC (permalink / raw)
To: ariga masahiro, ecos-discuss
> From: ariga masahiro [mailto:ariga@link-lab.co.jp]
>
> Forgive my ignorance,but please teach me more.
> If I like to insert exactly, say 20msec, delay how should I write
> program ?
You can't delay _exactly_ 20ms, you can only delay with an accuracy of 10ms.
Calling cyg_thread_delay(2) would delay more than 10ms but no more than
20ms.
Delays are implemented by a timer interrupt, which is happening all the
time, every 10ms, like the ticking of a clock, whether you're using it for
anything or not. When you call cyg_thread_delay(2), it puts the thread to
sleep, and sets its sleep count to 2 ticks. The next timer interrupt happens
between 0 and 10ms later, and decrements the sleep count for the thread to
1. The timer interrupt occurs 10ms later, decrements the sleep count to 0,
and wakes up the thread.
If you need perfectly accurate delays, while other threads and interrupts
are running, you can't do it, not with any RTOS. If you need somewhat more
accuracy, like 1ms accuracy, you can change the timer interrupt to run at
1KHz, and then call cyg_thread_delay(20) for a 20ms delay. That will give
you a delay that's more than 19ms but no more than 20ms. If you make the
timer interrupt run at 10KHz, you have 100us resolution. But the faster you
run the timer interrupt, the more of the CPU time will be wasted on timer
interrupts.
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: In trouble of timer operations
2008-05-30 4:11 ` ariga masahiro
2008-05-30 4:43 ` Paul D. DeRocco
@ 2008-05-30 6:35 ` Andrew Lunn
1 sibling, 0 replies; 41+ messages in thread
From: Andrew Lunn @ 2008-05-30 6:35 UTC (permalink / raw)
To: ariga masahiro; +Cc: Paul D. DeRocco, ecos-discuss
> Forgive my ignorance,but please teach me more.
> If I like to insert exactly, say 20msec, delay how should I write program ?
You can get better accuracy by using one of the spare hardware
timers. You would need to program it yourself, handle the interrupts,
block/unblock your thread etc.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: In trouble of timer operations
2008-05-30 4:43 ` Paul D. DeRocco
@ 2008-05-30 7:26 ` ariga masahiro
2008-05-30 7:47 ` Paul D. DeRocco
2008-05-30 8:07 ` Andrew Lunn
0 siblings, 2 replies; 41+ messages in thread
From: ariga masahiro @ 2008-05-30 7:26 UTC (permalink / raw)
To: Paul D. DeRocco, ecos-discuss
Hello Paul and others,
I am sorry perhaps I am slow in mind.
> You can't delay _exactly_ 20ms, you can only delay with an accuracy of
> 10ms.
OK,I re_state what I want.I like to hold delay as close as multiple of
10ms.
As for my first test I think result is too short.
Your first answer said.
> The ticks are 10ms apart, but your call to
> cyg_thread_delay
> isn't synchronized with these ticks.
I expected there are ways to synchronize with these ticks,and get as close
as 10ms delay.
And another thing.What I want to do is that I display time before calling
delay func(like cyg_thread_delay),
and display time again after returned from delay function.
Would you teach me how to do it.
I am very much obliged.
Masahiro Ariga
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* RE: [ECOS] Re: In trouble of timer operations
2008-05-30 7:26 ` ariga masahiro
@ 2008-05-30 7:47 ` Paul D. DeRocco
2008-05-30 8:03 ` ariga masahiro
2008-05-30 8:07 ` Andrew Lunn
1 sibling, 1 reply; 41+ messages in thread
From: Paul D. DeRocco @ 2008-05-30 7:47 UTC (permalink / raw)
To: ariga masahiro, eCos Discuss
> From: ariga masahiro
>
> OK,I re_state what I want.I like to hold delay as close as multiple of
> 10ms.
It might be helpful if we had an idea of what you actually need this delay
for. Let's say you need the software to turn on some hardware device at one
point in time, then turn it off some known amount of time later. If 10ms
granularity is sufficient, and it's acceptable to have both the turn-on and
turn-off occur on ticks of the existing system clock, then you could do a
one-tick delay to synchronize your thread to the clock, turn the device on,
delay some additional ticks, and then turn it off.
cyg_thread_delay(1);
control_something(TRUE);
cyg_thread_delay(n);
control_something(FALSE);
You'd get a pretty accurate n-tick delay between the two calls to
control_something(). But that assumes that no other thread of the same or
higher priority is running.
But if that's all you need, it's easier just to use an alarm object attached
to the system clock, and do whatever you need to do in the alarm handler. It
will run in DSR context, so can't do certain things like file I/O, but it
won't be pre-empted by anything else other than other ISRs and DSRs. A
thread could still control things either by setting static variables that
the alarm handler reads, or by explicitly enabling and disabling the alarm
as needed.
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: In trouble of timer operations
2008-05-30 7:47 ` Paul D. DeRocco
@ 2008-05-30 8:03 ` ariga masahiro
0 siblings, 0 replies; 41+ messages in thread
From: ariga masahiro @ 2008-05-30 8:03 UTC (permalink / raw)
To: Paul D. DeRocco, eCos Discuss
Hello Paul and others,
Thank you very much for your reply.
I will endeavor to fatham it.
Masahiro Ariga
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: In trouble of timer operations
2008-05-30 7:26 ` ariga masahiro
2008-05-30 7:47 ` Paul D. DeRocco
@ 2008-05-30 8:07 ` Andrew Lunn
2008-06-04 5:25 ` ariga masahiro
1 sibling, 1 reply; 41+ messages in thread
From: Andrew Lunn @ 2008-05-30 8:07 UTC (permalink / raw)
To: ariga masahiro; +Cc: Paul D. DeRocco, ecos-discuss
> I expected there are ways to synchronize with these ticks,and get as
> close as 10ms delay.
Simple
cyg_thread_delay(1);
cyg_thread_delay(1);
The second call will be roughly synchronised to the tick. The first
call will block until the tick. The second call will start shortly
after the tick and last until shortly after the next system tick.
I say roughly, because this is a RTOS. Any higher priority thread
which wakes up at this system tick will get to run first and so delay
when this thread gets to run.
> And another thing.What I want to do is that I display time before calling
> delay func(like cyg_thread_delay),
> and display time again after returned from delay function.
> Would you teach me how to do it.
I suggest you use a different hardware timer which is free
running. Set the period much higher so you don't have to deal with it
wrapping around every 10ms.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: In trouble of timer operations
2008-05-30 8:07 ` Andrew Lunn
@ 2008-06-04 5:25 ` ariga masahiro
2008-06-04 10:06 ` Paul D. DeRocco
0 siblings, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-06-04 5:25 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Paul D. DeRocco, ecos-discuss
[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]
Hello Andrew,Paul,and others,
I am afraid I dig up the same question but I think this is important,at
least for me,
so please forgive my inquiring again.
The problem is return_time of cyg_thread_delay.I am determined to use TMU1
as Free-Run Counter(0xffffffff-0)
and made function(HAL_CLOCK_READ1) to read TMU1 clock count.I am affirmed
it's working correctry.
I used it to calculate return time in hipri_test() in timeslice2.c.
I am baffled by the result.
--testing code
hipri_test(CYG_ADDRESS id)
{
cyg_int32 start;
while( 1 )
{
HAL_CLOCK_READ1(&start);
diag_printf("id=hi 0x%x\n",start);
cyg_thread_delay(1);
cyg_thread_delay(2);
}
}
I calculated several cases.
(1) I only used cyg_thread_delay(2)
(2) I used Andrew's proposition of using
cyg_thread_delay(1),cyg_thread_delay(2) like above code.
(3) same as (2) except changed cyg_thread_delay(2) to cyg_thread_delay(20)
(4) only used cyg_thread_delay(20)
result
(1) return value 1152.6microsec -- 1tick=576.3microsec
(2) return value 2041.7292mirosec
(3) return value 13286.6304microsec
(4) return value 12669.3792microsec -- 1tick=633.46microsec
I cannot help concluding that 1 tick takes only about 600microsec.
I checked related option values in untitled.ecc file.(I appended)
CYGNUM_HAL_RTC_NUMERATOR # Default value: 1000000000
CYGNUM_HAL_RTC_DENOMINATOR # Default value: 100
CYGNUM_HAL_RTC_PERIOD {
# CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED == 29491200
# CYGNUM_HAL_RTC_DENOMINATOR == 100
# CYGHWR_HAL_SH_RTC_PRESCALE == 4
# --> 73728
};
Since CYGNUM_HAL_RTC_DENOMINATOR=100,I guess clock interrupt frequency
should be 100H(=1 tick is 10millisec).
Please teach me where I am making mistakes.
If I am missing your points please forgive my ignorance and enlighten me.
Masahiro Ariga
[-- Attachment #2: untitled.ecc.gz --]
[-- Type: application/x-gzip, Size: 89721 bytes --]
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* RE: [ECOS] Re: In trouble of timer operations
2008-06-04 5:25 ` ariga masahiro
@ 2008-06-04 10:06 ` Paul D. DeRocco
2008-06-05 6:14 ` ariga masahiro
0 siblings, 1 reply; 41+ messages in thread
From: Paul D. DeRocco @ 2008-06-04 10:06 UTC (permalink / raw)
To: eCos Discuss
> From: ariga masahiro [mailto:ariga@link-lab.co.jp]
>
> I am afraid I dig up the same question but I think this is important,at
> least for me,
> so please forgive my inquiring again.
> The problem is return_time of cyg_thread_delay.I am determined to
> use TMU1
> as Free-Run Counter(0xffffffff-0)
> and made function(HAL_CLOCK_READ1) to read TMU1 clock count.I am affirmed
> it's working correctry.
> I used it to calculate return time in hipri_test() in timeslice2.c.
> I am baffled by the result.
>
> --testing code
> hipri_test(CYG_ADDRESS id)
> {
> cyg_int32 start;
>
> while( 1 )
> {
> HAL_CLOCK_READ1(&start);
> diag_printf("id=hi 0x%x\n",start);
> cyg_thread_delay(1);
> cyg_thread_delay(2);
> }
> }
> I calculated several cases.
> (1) I only used cyg_thread_delay(2)
> (2) I used Andrew's proposition of using
> cyg_thread_delay(1),cyg_thread_delay(2) like above code.
> (3) same as (2) except changed cyg_thread_delay(2) to cyg_thread_delay(20)
> (4) only used cyg_thread_delay(20)
It's possible that there's something wrong with the timer configuration.
However, you won't find it out very easily with diag_printf, because it
probably takes longer than 10ms to execute.
I don't know what hardware you're using, but most evaluation boards have
utility LEDs or output port pins. Instead of outputting a message, toggle a
port pin and look at it with a scope or a frequency counter.
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [ECOS] Re: In trouble of timer operations
2008-06-04 10:06 ` Paul D. DeRocco
@ 2008-06-05 6:14 ` ariga masahiro
2008-06-05 17:39 ` Paul D. DeRocco
0 siblings, 1 reply; 41+ messages in thread
From: ariga masahiro @ 2008-06-05 6:14 UTC (permalink / raw)
To: eCos Discuss, Paul D. DeRocco; +Cc: Andrew Lunn
Hello Paul,Andrew and others,
Thank you,Paul,for valuable suggestion.
I re_calculated by toggling LED and measured signal's duration on
osilloscope.
result
(1) only used cyg_thread_delay(2) -- 20.2millisec
(2) cyg_thread_delay(1),cyg_thread_delay(2) -- 30.1millisec
(3) same as (2) except changed cyg_thread_delay(2) to
yg_thread_delay(20) -- 212millisec
(4) only used cyg_thread_delay(20) -- 201millisec
I am confirmed in thinking that since CYGNUM_HAL_RTC_DENOMINATOR=100, system
clock is running 100Hz,1 tick perid = 10millisec,and if I wish to run system
clock 200Hz I should change CYGNUM_HAL_RTC_DENOMINATOR to 200.
But according to your mail, it raised another puzzlement.
> However, you won't find it out very easily with diag_printf, because it
> probably takes longer than 10ms to execute.
At first,I couldn't get it. Because if diag_printf takes over 10ms, simply
calculated results ought be longer,
but on the contrary it took far shorter than expected.
So I deliberately inserted
HAL_CLOCK_READ1(&start);
diag_printf("id=hi 0x%x\n",start);
in above each test(after led_toggle function) and investigated how it
affects duration time.
To my very astonishment as far as looking signals on osilloscope there are
no differences !
Two functions takes no time at all as far as looking to signals.
Can you resolve this wonder.
Please enlighten me.
Masahiro Ariga
>> From: ariga masahiro [mailto:ariga@link-lab.co.jp]
>>
>> I am afraid I dig up the same question but I think this is important,at
>> least for me,
>> so please forgive my inquiring again.
>> The problem is return_time of cyg_thread_delay.I am determined to
>> use TMU1
>> as Free-Run Counter(0xffffffff-0)
>> and made function(HAL_CLOCK_READ1) to read TMU1 clock count.I am affirmed
>> it's working correctry.
>> I used it to calculate return time in hipri_test() in timeslice2.c.
>> I am baffled by the result.
>>
>> --testing code
>> hipri_test(CYG_ADDRESS id)
>> {
>> cyg_int32 start;
>>
>> while( 1 )
>> {
>> HAL_CLOCK_READ1(&start);
>> diag_printf("id=hi 0x%x\n",start);
>> cyg_thread_delay(1);
>> cyg_thread_delay(2);
>> }
>> }
>> I calculated several cases.
>> (1) I only used cyg_thread_delay(2)
>> (2) I used Andrew's proposition of using
>> cyg_thread_delay(1),cyg_thread_delay(2) like above code.
>> (3) same as (2) except changed cyg_thread_delay(2) to
>> cyg_thread_delay(20)
>> (4) only used cyg_thread_delay(20)
>
> It's possible that there's something wrong with the timer configuration.
> However, you won't find it out very easily with diag_printf, because it
> probably takes longer than 10ms to execute.
>
> I don't know what hardware you're using, but most evaluation boards have
> utility LEDs or output port pins. Instead of outputting a message, toggle
> a
> port pin and look at it with a scope or a frequency counter.
>
> --
>
> Ciao, Paul D. DeRocco
> Paul mailto:pderocco@ix.netcom.com
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* RE: [ECOS] Re: In trouble of timer operations
2008-06-05 6:14 ` ariga masahiro
@ 2008-06-05 17:39 ` Paul D. DeRocco
0 siblings, 0 replies; 41+ messages in thread
From: Paul D. DeRocco @ 2008-06-05 17:39 UTC (permalink / raw)
To: eCos Discuss
> From: ariga masahiro
>
> Thank you,Paul,for valuable suggestion.
> I re_calculated by toggling LED and measured signal's duration on
> osilloscope.
>
> result
> (1) only used cyg_thread_delay(2) -- 20.2millisec
> (2) cyg_thread_delay(1),cyg_thread_delay(2) -- 30.1millisec
> (3) same as (2) except changed cyg_thread_delay(2) to
> yg_thread_delay(20) -- 212millisec
> (4) only used cyg_thread_delay(20) -- 201millisec
>
> I am confirmed in thinking that since
> CYGNUM_HAL_RTC_DENOMINATOR=100, system
> clock is running 100Hz,1 tick perid = 10millisec,and if I wish to
> run system
> clock 200Hz I should change CYGNUM_HAL_RTC_DENOMINATOR to 200.
>
> But according to your mail, it raised another puzzlement.
>
> > However, you won't find it out very easily with diag_printf, because it
> > probably takes longer than 10ms to execute.
>
> At first,I couldn't get it. Because if diag_printf takes over
> 10ms, simply
> calculated results ought be longer,
> but on the contrary it took far shorter than expected.
>
> So I deliberately inserted
> HAL_CLOCK_READ1(&start);
> diag_printf("id=hi 0x%x\n",start);
> in above each test(after led_toggle function) and investigated how it
> affects duration time.
> To my very astonishment as far as looking signals on osilloscope
> there are
> no differences !
> Two functions takes no time at all as far as looking to signals.
Well, then the diag_printf is running fast enough on your system. That
depends upon the bit rate. On a system running at 115200, outputting 18
characters takes about 1.5ms, which is short enough, but running at 9600
takes 19ms, which would cause a problem.
If your loop is running at the right rate according to the scope, but your
diag_printf messages show something different, then it sounds like you've
proven that your HAL hardware clock isn't running at the speed you think it
is.
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
* [ECOS] Wrongfully compiled code
2007-11-06 8:35 ` Andrew Lunn
@ 2008-01-07 1:36 ` ariga masahiro
0 siblings, 0 replies; 41+ messages in thread
From: ariga masahiro @ 2008-01-07 1:36 UTC (permalink / raw)
To: ecos-discuss
Hello,
Happy New Year.
I am encountered next phenomenon and I am very in deep trouble.
It happens when sending back TCP SYN-ACK packet to peer,
and it happens in
packages\net\bsd_tcpip\current\src\sys\netinet\tcp_output.c
tcp_output()function.
I attach C source code,and corresponding mixed source code below.
Please refer to them.
I traced source code using ICE. (numbers are source line numbers)
First,on line 398 hdrlen becomes 0x28.And optlen becomes 4 on line 408.
Althoug it should execute
512: hdrlen += optlen;
but looks it passed in C code trace.
And on line
| 643: m->m_len = hdrlen; -- hdrlen is still 0x28
hdrlen is 0x28,although it should be 0x2c.
I could have traced same part in mixed source mode,and I discovered it was
wrongfully compiled.
I explain in detail after the source code.
Below are C code source and corresponding mixed source(from 445 line onward
in C source).
-- tcp_output() C source code
383: send:
384: /*
385: * Before ESTABLISHED, force sending of initial options
386: * unless TCP set not to do any options.
387: * NOTE: we assume that the IP/TCP header plus TCP options
388: * always fit in a single mbuf, leaving room for a maximum
389: * link header, i.e.
390: * max_linkhdr + sizeof (struct tcpiphdr) + optlen <=
MCLBYTES
391: */
392: optlen = 0;
393: #ifdef INET6
394: if (isipv6)
395: hdrlen = sizeof (struct ip6_hdr) + sizeof (struct
tcphdr);
396: else
397: #endif
-> 398: hdrlen = sizeof (struct tcpiphdr); -- here hdrlen becomes
0x28
| 399: if (flags & TH_SYN) {
| 400: tp->snd_nxt = tp->iss;
| 401: if ((tp->t_flags & TF_NOOPT) == 0) {
402: u_short mss;
403:
| 404: opt[0] = TCPOPT_MAXSEG;
| 405: opt[1] = TCPOLEN_MAXSEG;
| 406: mss = htons((u_short) tcp_mssopt(tp));
| 407: (void)memcpy(opt + 2, &mss, sizeof(mss));
| 408: optlen = TCPOLEN_MAXSEG;
409:
| 410: if ((tp->t_flags & TF_REQ_SCALE) && --428,É"n,Ô
411: ((flags & TH_ACK) == 0 ||
412: (tp->t_flags & TF_RCVD_SCALE))) {
413: *((u_int32_t *)(opt + optlen)) = htonl(
414: TCPOPT_NOP << 24 |
415: TCPOPT_WINDOW << 16 |
416: TCPOLEN_WINDOW << 8 |
417: tp->request_r_scale);
418: optlen += 4;
419: }
420: }
421: }
422:
423: /*
424: * Send a timestamp and echo-reply if this is a SYN and our
side
425: * wants to use timestamps (TF_REQ_TSTMP is set) or both our
side
426: * and our peer have sent timestamps in our SYN's.
427: */
-> 428: if ((tp->t_flags & (TF_REQ_TSTMP|TF_NOOPT)) == TF_REQ_TSTMP
&&
429: (flags & TH_RST) == 0 &&
430: ((flags & TH_ACK) == 0 ||
431: (tp->t_flags & TF_RCVD_TSTMP))) {
432: u_int32_t *lp = (u_int32_t *)(opt + optlen);
433:
434: /* Form timestamp option as shown in appendix A of RFC
1323. */
435: *lp++ = htonl(TCPOPT_TSTAMP_HDR);
436: *lp++ = htonl(ticks);
437: *lp = htonl(tp->ts_recent);
438: optlen += TCPOLEN_TSTAMP_APPA;
439: }
440:
441: /*
442: * Send `CC-family' options if our side wants to use them
(TF_REQ_CC),
443: * options are allowed (!TF_NOOPT) and it's not a RST.
444: */
-> 445: if ((tp->t_flags & (TF_REQ_CC|TF_NOOPT)) == TF_REQ_CC &&
446: (flags & TH_RST) == 0) {
447: switch (flags & (TH_SYN|TH_ACK)) {
448: /*
449: * This is a normal ACK, send CC if we received CC
before
450: * from our peer.
451: */
452: case TH_ACK:
453: if (!(tp->t_flags & TF_RCVD_CC))
454: break;
455: /*FALLTHROUGH*/
456:
457: /*
458: * We can only get here in T/TCP's SYN_SENT* state, when
459: * we're a sending a non-SYN segment without waiting for
460: * the ACK of our SYN. A check above assures that we
only
461: * do this if our peer understands T/TCP.
462: */
463: case 0:
464: opt[optlen++] = TCPOPT_NOP;
465: opt[optlen++] = TCPOPT_NOP;
466: opt[optlen++] = TCPOPT_CC;
467: opt[optlen++] = TCPOLEN_CC;
468: *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);
469:
470: optlen += 4;
471: break;
472:
473: /*
474: * This is our initial SYN, check whether we have to use
475: * CC or CC.new.
476: */
477: case TH_SYN:
478: opt[optlen++] = TCPOPT_NOP;
479: opt[optlen++] = TCPOPT_NOP;
480: opt[optlen++] = tp->t_flags & TF_SENDCCNEW ?
481: TCPOPT_CCNEW : TCPOPT_CC;
482: opt[optlen++] = TCPOLEN_CC;
483: *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);
484: optlen += 4;
485: break;
486:
487: /*
488: * This is a SYN,ACK; send CC and CC.echo if we received
489: * CC from our peer.
490: */
491: case (TH_SYN|TH_ACK):
492: if (tp->t_flags & TF_RCVD_CC) {
493: opt[optlen++] = TCPOPT_NOP;
494: opt[optlen++] = TCPOPT_NOP;
495: opt[optlen++] = TCPOPT_CC;
496: opt[optlen++] = TCPOLEN_CC;
497: *(u_int32_t *)&opt[optlen] =
498: htonl(tp->cc_send);
499: optlen += 4;
500: opt[optlen++] = TCPOPT_NOP;
501: opt[optlen++] = TCPOPT_NOP;
502: opt[optlen++] = TCPOPT_CCECHO;
503: opt[optlen++] = TCPOLEN_CC;
504: *(u_int32_t *)&opt[optlen] =
505: htonl(tp->cc_recv);
506: optlen += 4;
507: }
508: break;
509: }
510: }
511:
512: hdrlen += optlen;
and try to convert m->m_len,
-> 642: m->m_data += max_linkhdr;
| 643: m->m_len = hdrlen; -- hdrlen is still 0x28
--- Mix source code corresponding to C code
tcp_output.c (445): if ((tp->t_flags & (TF_REQ_CC|TF_NOOPT)) == TF_REQ_CC
&&
8C048BA4 51AA MOV.L @(28,R10 tp ),R1
8C048BA6 9214 MOV.W 8C048BD2,R2
8C048BA8 2129 AND R2,R1
8C048BAA 72F8 ADD #F8,R2
8C048BAC 3120 CMP/EQ R2,R1
8C048BAE 8F51 BF/S
4 ->1
8C048BB0 60D3 MOV R13 flags ,R0
8C048BB2 C904 AND #4,R0
8C048BB4 2008 TST R0,R0
8C048BB6 8F4D BF/S 8C048C54
8C048BB8 E212 MOV #12,R2
tcp_output.c (447): switch (flags & (TH_SYN|TH_ACK)) {
8C048BBA 22D9 AND R13 flags ,R2
8C048BBC E112 MOV #12,R1
8C048BBE 3216 CMP/HI R1,R2
8C048BC0 8948 BT 8C048C54
8C048BC2 C70A MOVA 8C048BEC,R0
8C048BC4 322C ADD R2,R2
8C048BC6 012D MOV.W @(R0,R2),R1
8C048BC8 0123 BRAF R1
8C048BCA 0009 NOP
8C048BCC 00AC MOV.B @(R0,R10 tp ),R0
8C048BCE 0080 ???
8C048BD0 0100 ???
8C048BD2 2008 TST R0,R0
8C048BD4 8C02 ???
8C048BD6 9D60 MOV.W 8C048C9A,R13 flags
8C048BD8 8C04 ???
8C048BDA 94A0 MOV.W 8C048D1E,R4
8C048BDC 8C04 ???
8C048BDE 8600 ???
8C048BE0 0103 BSRF R1
8C048BE2 0300 ???
8C048BE4 0101 ???
8C048BE6 080A STS MACH,R8 error
8C048BE8 8C02 ???
8C048BEA 8BF0 BF 8C048BCE
8C048BEC 005C MOV.B @(R0,R5),R0
8C048BEE 0124 MOV.B R2,@(R0,R1)
8C048BF0 0094 MOV.B R9,@(R0,R0)
8C048BF2 0124 MOV.B R2,@(R0,R1)
8C048BF4 0124 MOV.B R2,@(R0,R1)
8C048BF6 0124 MOV.B R2,@(R0,R1)
8C048BF8 0124 MOV.B R2,@(R0,R1)
8C048BFA 0124 MOV.B R2,@(R0,R1)
8C048BFC 0124 MOV.B R2,@(R0,R1)
8C048BFE 0124 MOV.B R2,@(R0,R1)
8C048C00 0124 MOV.B R2,@(R0,R1)
8C048C02 0124 MOV.B R2,@(R0,R1)
8C048C04 0124 MOV.B R2,@(R0,R1)
8C048C06 0124 MOV.B R2,@(R0,R1)
8C048C08 0124 MOV.B R2,@(R0,R1)
8C048C0A 0124 MOV.B R2,@(R0,R1)
8C048C0C 0054 MOV.B R5,@(R0,R0)
8C048C0E 0124 MOV.B R2,@(R0,R1)
8C048C10 00D4 MOV.B R13 flags ,@(R0,R0)
8C048C12 0009 NOP
8C048C14 0009 NOP
8C048C16 0009 NOP
8C048C18 0009 NOP
8C048C1A 0009 NOP
8C048C1C 0009 NOP
8C048C1E 0009 NOP
tcp_output.c (453): if (!(tp->t_flags & TF_RCVD_CC))
8C048C20 52AA MOV.L @(28,R10 tp ),R2
8C048C22 91B2 MOV.W 8C048D8A,R1
8C048C24 2218 TST R1,R2
8C048C26 8963 BT 8C048CF0
tcp_output.c (464): opt[optlen++] = TCPOPT_NOP;
8C048C28 E101 MOV #1,R1
8C048C2A E048 MOV #48,R0
8C048C2C 00EE MOV.L @(R0,R14),R0
8C048C2E 0E14 MOV.B R1,@(R0,R14)
8C048C30 7001 ADD #1,R0
8C048C32 E240 MOV #40,R2
8C048C34 32EC ADD R14,R2
tcp_output.c (465): opt[optlen++] = TCPOPT_NOP;
8C048C36 0E14 MOV.B R1,@(R0,R14)
8C048C38 7001 ADD #1,R0
tcp_output.c (466): opt[optlen++] = TCPOPT_CC;
8C048C3A E10B MOV #B,R1
8C048C3C 0E14 MOV.B R1,@(R0,R14)
8C048C3E 7001 ADD #1,R0
tcp_output.c (467): opt[optlen++] = TCPOLEN_CC;
8C048C40 E106 MOV #6,R1
8C048C42 0E14 MOV.B R1,@(R0,R14)
8C048C44 7001 ADD #1,R0
8C048C46 1202 MOV.L R0,@(8,R2)
tcp_output.c (468): *(u_int32_t *)&opt[optlen] =
htonl(tp->cc_send);
8C048C48 90A0 MOV.W 8C048D8C,R0
8C048C4A 01AE MOV.L @(R0,R10 tp ),R1
8C048C4C 5022 MOV.L @(8,R2),R0
8C048C4E 0E16 MOV.L R1,@(R0,R14)
tcp_output.c (470): optlen += 4;
8C048C50 7004 ADD #4,R0
8C048C52 1202 MOV.L R0,@(8,R2)
->1 8C048C54 A04D BRA 8C048CF2 ->2
tcp_output.c (471): break;
8C048C56 E740 MOV #40,R7
8C048C58 0009 NOP
8C048C5A 0009 NOP
8C048C5C 0009 NOP
8C048C5E 0009 NOP
tcp_output.c (478): opt[optlen++] = TCPOPT_NOP;
8C048C60 E101 MOV #1,R1
8C048C62 E048 MOV #48,R0
8C048C64 00EE MOV.L @(R0,R14),R0
8C048C66 0E14 MOV.B R1,@(R0,R14)
8C048C68 7001 ADD #1,R0
tcp_output.c (479): opt[optlen++] = TCPOPT_NOP;
8C048C6A 0E14 MOV.B R1,@(R0,R14)
8C048C6C 7001 ADD #1,R0
tcp_output.c (480): opt[optlen++] = tp->t_flags & TF_SENDCCNEW ?
8C048C6E 6303 MOV R0,R3 ipoptlen
8C048C70 33EC ADD R14,R3 ipoptlen
8C048C72 7001 ADD #1,R0
8C048C74 52AA MOV.L @(28,R10 tp ),R2
8C048C76 D146 MOV.L 8C048D90,R1
8C048C78 2218 TST R1,R2
8C048C7A 0129 MOVT R1
8C048C7C 611B NEG R1,R1
8C048C7E 710C ADD #C,R1
8C048C80 2310 MOV.B R1,@R3 ipoptlen
tcp_output.c (482): opt[optlen++] = TCPOLEN_CC;
8C048C82 E106 MOV #6,R1
8C048C84 0E14 MOV.B R1,@(R0,R14)
8C048C86 7001 ADD #1,R0
8C048C88 E640 MOV #40,R6
8C048C8A 36EC ADD R14,R6
8C048C8C 1602 MOV.L R0,@(8,R6)
tcp_output.c (483): *(u_int32_t *)&opt[optlen] =
htonl(tp->cc_send);
8C048C8E 907D MOV.W 8C048D8C,R0
8C048C90 01AE MOV.L @(R0,R10 tp ),R1
8C048C92 A029 BRA 8C048CE8
tcp_output.c (485): break;
8C048C94 5062 MOV.L @(8,R6),R0
8C048C96 0009 NOP
8C048C98 0009 NOP
8C048C9A 0009 NOP
8C048C9C 0009 NOP
8C048C9E 0009 NOP
tcp_output.c (492): if (tp->t_flags & TF_RCVD_CC) {
8C048CA0 52AA MOV.L @(28,R10 tp ),R2
8C048CA2 9172 MOV.W 8C048D8A,R1
8C048CA4 2218 TST R1,R2
8C048CA6 8D24 BT/S 8C048CF2
8C048CA8 E740 MOV #40,R7
tcp_output.c (493): opt[optlen++] = TCPOPT_NOP;
8C048CAA E201 MOV #1,R2
8C048CAC E048 MOV #48,R0
8C048CAE 00EE MOV.L @(R0,R14),R0
8C048CB0 0E24 MOV.B R2,@(R0,R14)
8C048CB2 7001 ADD #1,R0
tcp_output.c (494): opt[optlen++] = TCPOPT_NOP;
8C048CB4 0E24 MOV.B R2,@(R0,R14)
8C048CB6 7001 ADD #1,R0
tcp_output.c (495): opt[optlen++] = TCPOPT_CC;
8C048CB8 E10B MOV #B,R1
8C048CBA 0E14 MOV.B R1,@(R0,R14)
8C048CBC 7001 ADD #1,R0
8C048CBE E640 MOV #40,R6
8C048CC0 36EC ADD R14,R6
tcp_output.c (496): opt[optlen++] = TCPOLEN_CC;
8C048CC2 E706 MOV #6,R7
8C048CC4 0E74 MOV.B R7,@(R0,R14)
8C048CC6 7001 ADD #1,R0
tcp_output.c (497): *(u_int32_t *)&opt[optlen] =
8C048CC8 9160 MOV.W 8C048D8C,R1
8C048CCA 63A3 MOV R10 tp ,R3 ipoptlen
8C048CCC 331C ADD R1,R3 ipoptlen
8C048CCE 5130 MOV.L @(0,R3 ipoptlen ),R1
8C048CD0 0E16 MOV.L R1,@(R0,R14)
tcp_output.c (499): optlen += 4;
8C048CD2 7004 ADD #4,R0
tcp_output.c (500): opt[optlen++] = TCPOPT_NOP;
8C048CD4 0E24 MOV.B R2,@(R0,R14)
8C048CD6 7001 ADD #1,R0
tcp_output.c (501): opt[optlen++] = TCPOPT_NOP;
8C048CD8 0E24 MOV.B R2,@(R0,R14)
8C048CDA 7001 ADD #1,R0
tcp_output.c (502): opt[optlen++] = TCPOPT_CCECHO;
8C048CDC E10D MOV #D,R1
8C048CDE 0E14 MOV.B R1,@(R0,R14)
8C048CE0 7001 ADD #1,R0
tcp_output.c (503): opt[optlen++] = TCPOLEN_CC;
8C048CE2 0E74 MOV.B R7,@(R0,R14)
8C048CE4 7001 ADD #1,R0
tcp_output.c (504): *(u_int32_t *)&opt[optlen] =
8C048CE6 5131 MOV.L @(4,R3 ipoptlen ),R1
8C048CE8 0E16 MOV.L R1,@(R0,R14)
tcp_output.c (506): optlen += 4;
8C048CEA 7004 ADD #4,R0
8C048CEC 1602 MOV.L R0,@(8,R6)
8C048CEE 0009 NOP
tcp_output.c (512): hdrlen += optlen;
8C048CF0 E740 MOV #40,R7
->2 8C048CF2 37EC ADD R14,R7
8C048CF4 5073 MOV.L @(C,R7),R0
8C048CF6 5772 MOV.L @(8,R7),R7
8C048CF8 307C ADD R7,R0
8C048CFA 1703 MOV.L R0,@(C,R7)
tcp_output.c (520): if (tp->t_inpcb->inp_options) {
8C048CFC 51A8 MOV.L @(20,R10 tp ),R1
8C048CFE 9046 MOV.W 8C048D8E,R0
8C048D00 011E MOV.L @(R0,R1),R1
8C048D02 2118 TST R1,R1
8C048D04 8904 BT 8C048D10
8C048D06 5113 MOV.L @(C,R1),R1
tcp_output.c (521): ipoptlen = tp->t_inpcb->inp_options->m_len -
In detail.
Like I said,at line-445 hdrlen is 0x28,and optlen is 4.
After that it jump to address 8C048CF2(->2).
About @(disp:4,Rn) assembler operation,next is from SH assembler manual,
"The effective address is Rn plus a 4-bit displacement
(disp). The value of disp is zero-extended, and
remains the same for a byte operation, is doubled for
a word operation, and is quadrupled for a longword
operation."
When jumped to 8C048CF2, R14=8c081458,R7=00000040.
Added,R7 becomes 8c081498.
After executing (MOV.L @(C,R7),R0),R0 becomes 0x28.
But here it acts qeerly,according to manual,0x28 should be retrieved
from 8c081498+c*4=8c0814c8, but really it was retreived from 8c0814a4.
It looks there's no extension according to operand size.But this is minor
point.
Anyway,after executing next line(MOV.L @(8,R7),R7),R7 becomes 4.
By (ADD R7,R0),R0 becomes 0x2c,this is expected value for hdrlen.
But,by (MOV.L R0,@(C,R7)),content of R0 is reserved into 0x00000010.(really
it can't be written).
Content of hdrlen(8c0814a4) remains 0x28.
I executed without ICE but resulted in IP packet size being 0x28,although it
should be 0x2c.
I am perplexed why this phenomenon happens.
Please enlighten me what do you think causes this mishappening.
My target CPU is SH7709S.
I am developing on Cygwin environment.
I checked sh-elf-gcc version and it was version 3.2.1.
$ sh-elf-gcc -v
Reading specs from
/opt/ecos/gnutools/sh-elf/bin/../lib/gcc-lib/sh-elf/3.2.1/spe
cs
Configured with:
/local/demonweb/tools/ecos-gnutools-v1.4/r2/sh-elf/cygwin/tar_b
z2/source/gcc-3.2.1/configure --target=sh-elf --prefix=/local/demonweb/tools/eco
s-gnutools-v1.4/r2/sh-elf/cygwin/tar_bz2/opt/ecos/gnutools/sh-elf --enable-langu
ages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-gxx-include-dir=/loc
al/demonweb/tools/ecos-gnutools-v1.4/r2/sh-elf/cygwin/tar_bz2/opt/ecos/gnutools/
sh-elf/sh-elf/include
Thread model: single
gcc version 3.2.1
My compile option is same as CVS downloaded version for se77x9,
cdl_option CYGBLD_GLOBAL_CFLAGS {
display "Global compiler flags"
flavor data
no_define
default_value { CYGHWR_HAL_SH_BIGENDIAN ?
"-D_KERNEL -D__ECOS -mb -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline
-Wundef -Woverloaded-virtual -ggdb -O1 -ffunction-sections -fdata-sections
-fno-rtti -fno-exceptions -fvtable-gc -finit-priority" :
"-D_KERNEL -D__ECOS -ml -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline
-Wundef -Woverloaded-virtual -ggdb -O1 -ffunction-sections -fdata-sections
-fno-rtti -fno-exceptions -fvtable-gc -finit-priority" }
description "
This option controls the global compiler flags which
are used to compile all packages by
default. Individual packages may define
options which override these global flags."
}
cdl_option CYGBLD_GLOBAL_LDFLAGS {
display "Global linker flags"
flavor data
no_define
default_value { CYGHWR_HAL_SH_BIGENDIAN ?
"-mb -m3 -ggdb -nostdlib -Wl,--gc-sections -Wl,-static" :
"-ml -m3 -ggdb -nostdlib -Wl,--gc-sections -Wl,-static" }
description "
This option controls the global linker flags. Individual
packages may define options which override these global
flags."
}
CYGHWR_HAL_SH_BIGENDIAN is valid.
My ICE works on Windows so I would like to develop on Cygwin environment.
I bessech you to help me.
Thanks in advance.
Masahiro Ariga
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2008-06-05 17:39 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-07 23:59 [ECOS] Wrongfully compiled code ariga masahiro
2008-01-08 0:05 ` Gary Thomas
2008-01-08 1:05 ` ariga masahiro
2008-01-17 19:21 ` [ECOS] " Dave Lawrence
2008-01-17 23:50 ` ariga masahiro
2008-01-18 12:16 ` Dave Lawrence
2008-01-18 14:40 ` Gregg Levine
2008-01-18 15:44 ` Dave Lawrence
2008-01-18 15:49 ` Gregg Levine
2008-01-18 16:09 ` Dave Lawrence
2008-01-21 0:34 ` ariga masahiro
2008-02-04 1:49 ` ariga masahiro
2008-02-04 11:38 ` Dave Lawrence
2008-02-12 1:06 ` ariga masahiro
2008-02-12 10:55 ` Dave Lawrence
2008-02-22 4:57 ` [ECOS] How to re-install newly compiled gnutools ariga masahiro
2008-02-22 7:15 ` ariga masahiro
2008-05-16 8:13 ` [ECOS] When or on what condition does "deschedule" happen? ariga masahiro
2008-05-16 15:26 ` Andrew Lunn
2008-05-19 5:32 ` ariga masahiro
2008-05-19 13:18 ` Andrew Lunn
2008-05-19 13:31 ` Gary Thomas
2008-05-20 1:26 ` ariga masahiro
2008-05-20 12:18 ` Andrew Lunn
2008-05-23 7:38 ` ariga masahiro
2008-05-23 9:35 ` Nick Garnett
[not found] ` <000601c8c165$406e0970$1c0110ac@ariga>
2008-05-29 18:23 ` [ECOS] Re: In trouble of timer operations Andrew Lunn
2008-05-30 2:50 ` ariga masahiro
2008-05-30 3:09 ` Paul D. DeRocco
2008-05-30 4:11 ` ariga masahiro
2008-05-30 4:43 ` Paul D. DeRocco
2008-05-30 7:26 ` ariga masahiro
2008-05-30 7:47 ` Paul D. DeRocco
2008-05-30 8:03 ` ariga masahiro
2008-05-30 8:07 ` Andrew Lunn
2008-06-04 5:25 ` ariga masahiro
2008-06-04 10:06 ` Paul D. DeRocco
2008-06-05 6:14 ` ariga masahiro
2008-06-05 17:39 ` Paul D. DeRocco
2008-05-30 6:35 ` Andrew Lunn
-- strict thread matches above, loose matches on Subject: below --
2007-10-18 11:12 [ECOS] What functions should I call in ethernet drv ? Gary Thomas
2007-10-19 4:56 ` ariga masahiro
2007-10-19 9:55 ` Gary Thomas
2007-10-23 8:23 ` ariga masahiro
2007-10-23 8:27 ` Alok Singh
2007-10-25 2:05 ` ariga masahiro
2007-10-30 2:41 ` [ECOS] Can't Connect,TCP CHECKSUM INCORRECT ariga masahiro
2007-11-06 7:14 ` ariga masahiro
2007-11-06 7:58 ` Alok Singh
2007-11-06 8:30 ` ariga masahiro
2007-11-06 8:35 ` Andrew Lunn
2008-01-07 1:36 ` [ECOS] Wrongfully compiled code ariga masahiro
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).