headers
Sergei Gavrikov | 1 Mar 2012 08:25
Picon

Re: Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

On Wed, 29 Feb 2012, Grant Edwards wrote:

> Now I've got -Wno-write-strings (as seen above), but I still get 139
> warnings, and 88 of them are because of dereferencing type-punned
> pointers by bsd_tcpip files.
> 
> It still looks to me like the bsd_tcpip cdl needs to add
> -fno-strict-aliasing to CFLAGS.
> 
> After doing that, I'm down to 51 warnings.
> 
> 39 are variables that are set but not used -- almost all in bsd_tcpip
> files.
> 
> Most of the rest are signed/unsigned mismatches for pointer arguments.
> Again, almost all are in bsd_tcpip code.

Grant, I found what opens Pandora's box thanking your questions on ipv6
stack :-) That is ipv6 code! As I could understand you include it and I
used only ipv4 stack when I tested new toolchain. With the option

  cdl_option CYGPKG_NET_INET6 {
      user_value 1
  };

I got the same results on warnings as you have.

BTW, current and stable GCC-4.3.2 does produce something about 10
warnings for the same build.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sergei Gavrikov | 1 Mar 2012 13:09
Picon

Re: Re: Disable IPv6 at startup?

On Wed, 29 Feb 2012, Grant Edwards wrote:

[snip]

> OK, I've come up with something I like a little better.  The only
> change it requires to the network stack is that ip6_init2() needs to
> be globally visible (ip6_init already is, so I don't see the harm in
> making ip6_init2 visible).  If ip6_init2 is visible, then you can
> disable ipv6 support with this code:
> 
> static void init_noop(void* dummy)
> {
> }
> 
> static void disable_ipv6(void)
> {
>   extern void cyg_net_add_domain(void *);
>   extern void ip6_init2(void *);
>   extern char inet6domain[];
>   extern struct init_tab_entry __NET_INIT_TAB__[], __NET_INIT_TAB_END__;
>   struct init_tab_entry *init_entry;
> 
>   for (init_entry = __NET_INIT_TAB__; init_entry != &__NET_INIT_TAB_END__;  init_entry++) 
>       if ((init_entry->fun == cyg_net_add_domain && init_entry->data == (void*)inet6domain) ||
>           (init_entry->fun == ip6_init2))
>           init_entry->fun = init_noop;
> }

IMHO, it is neat solution. Thanks for usage example. BTW, the KAME's
successors had declared ip6_init2() as you suggest:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Elad Yosef | 1 Mar 2012 15:24
Picon

MATH LIB - does it have float support

Hi,
I'm trying to use single-precision functions such as roundf but I get errors.
My math Lib is using IEEE only.
Does the math lib has the required API ?

I'm using MIPS32

Elad

--

-- 
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 | Reply | 3 comments |
headers
Grant Edwards | 1 Mar 2012 15:31
Picon

Re: eCos arm-eabi GNU tools - test release 4.6.2-20120125

On 2012-03-01, Sergei Gavrikov <sergei.gavrikov <at> gmail.com> wrote:
> On Wed, 29 Feb 2012, Grant Edwards wrote:
>
>> Now I've got -Wno-write-strings (as seen above), but I still get 139
>> warnings, and 88 of them are because of dereferencing type-punned
>> pointers by bsd_tcpip files.
>> 
>> It still looks to me like the bsd_tcpip cdl needs to add
>> -fno-strict-aliasing to CFLAGS.
>> 
>> After doing that, I'm down to 51 warnings.
>> 
>> 39 are variables that are set but not used -- almost all in bsd_tcpip
>> files.
>> 
>> Most of the rest are signed/unsigned mismatches for pointer arguments.
>> Again, almost all are in bsd_tcpip code.
>
> Grant, I found what opens Pandora's box thanking your questions on ipv6
> stack :-) That is ipv6 code! As I could understand you include it and I
> used only ipv4 stack when I tested new toolchain. With the option
>
>   cdl_option CYGPKG_NET_INET6 {
>       user_value 1
>   };
>
> I got the same results on warnings as you have.

Ah!  That's good to know.  I was starting to wonder what I was doing
wrong. :)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Edwards | 1 Mar 2012 15:35
Picon

Re: Disable IPv6 at startup?

On 2012-03-01, Sergei Gavrikov <sergei.gavrikov <at> gmail.com> wrote:
> On Wed, 29 Feb 2012, Grant Edwards wrote:
>
> [snip]
>
>> OK, I've come up with something I like a little better.  The only
>> change it requires to the network stack is that ip6_init2() needs to
>> be globally visible (ip6_init already is, so I don't see the harm in
>> making ip6_init2 visible).  If ip6_init2 is visible, then you can
>> disable ipv6 support with this code:
>> 
>> static void init_noop(void* dummy)
>> {
>> }
>> 
>> static void disable_ipv6(void)
>> {
>>   extern void cyg_net_add_domain(void *);
>>   extern void ip6_init2(void *);
>>   extern char inet6domain[];
>>   extern struct init_tab_entry __NET_INIT_TAB__[], __NET_INIT_TAB_END__;
>>   struct init_tab_entry *init_entry;
>> 
>>   for (init_entry = __NET_INIT_TAB__; init_entry != &__NET_INIT_TAB_END__;  init_entry++) 
>>       if ((init_entry->fun == cyg_net_add_domain && init_entry->data == (void*)inet6domain) ||
>>           (init_entry->fun == ip6_init2))
>>           init_entry->fun = init_noop;
>> }

In case anybody is wondering, ip6_init() is called via the domain
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sergei Gavrikov | 1 Mar 2012 18:24
Picon

Re: Re: Disable IPv6 at startup?

On Thu, 1 Mar 2012, Grant Edwards wrote:

> On 2012-03-01, Sergei Gavrikov wrote:
> > On Wed, 29 Feb 2012, Grant Edwards wrote:
> >
> > [snip]
> >
> >> OK, I've come up with something I like a little better.  The only
> >> change it requires to the network stack is that ip6_init2() needs to
> >> be globally visible (ip6_init already is, so I don't see the harm in
> >> making ip6_init2 visible).  If ip6_init2 is visible, then you can
> >> disable ipv6 support with this code:
> >> 
> >> static void init_noop(void* dummy)
> >> {
> >> }
> >> 
> >> static void disable_ipv6(void)
> >> {
> >>   extern void cyg_net_add_domain(void *);
> >>   extern void ip6_init2(void *);
> >>   extern char inet6domain[];
> >>   extern struct init_tab_entry __NET_INIT_TAB__[], __NET_INIT_TAB_END__;
> >>   struct init_tab_entry *init_entry;
> >> 
> >>   for (init_entry = __NET_INIT_TAB__; init_entry != &__NET_INIT_TAB_END__;  init_entry++) 
> >>       if ((init_entry->fun == cyg_net_add_domain && init_entry->data == (void*)inet6domain) ||
> >>           (init_entry->fun == ip6_init2))
> >>           init_entry->fun = init_noop;
> >> }
(Continue reading)

Permalink | Reply | 2 comments |
headers
Grant Edwards | 1 Mar 2012 20:19
Picon

Re: Disable IPv6 at startup?

On 2012-03-01, Sergei Gavrikov <sergei.gavrikov <at> gmail.com> wrote:

>>> IMHO, it is neat solution. Thanks for usage example. BTW, the KAME's
>>> successors had declared ip6_init2() as you suggest:
>>>
>>>   http://ftp.fr.openbsd.org/pub/OpenBSD/src/sys/netinet6/ip6_input.c
>>>
>>> Please, submit the patch.
>> 
>> OK, will do.  I noticed after that last post that ip6_init is renamed
>> to cyg_ip6_init by one of the include files.
>
> Yes, I'm seeing that was entered in a merge/fix patch from Kelvin Lawson
> in 2011. But there is also
>
>   include/sys/param.h:224:#define ip6_init cyg_ip6_init
>
>> I assume I should do the same thing for ip6_init2 if it's going to be
>> global?
>
> I have doubt.  May be to change a scope of the function in ip6_input.c
> will be enough for the case?  As for me I would not propagate the
> definition {cyg_,}ip6_init2 in the headers.  Though, may be I wrong
> here. I would stop on your first proposal:
>
>  -static void ...
>  +void ...

I've already submitted a patch with the #define added, but if the
consensus is to leave the symbol un-mangled, then I can submit a new
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sergei Gavrikov | 1 Mar 2012 20:51
Picon

Re: Re: Disable IPv6 at startup?

On Thu, 1 Mar 2012, Grant Edwards wrote:

> On 2012-03-01, Sergei Gavrikov wrote:
> 
> >>> IMHO, it is neat solution. Thanks for usage example. BTW, the KAME's
> >>> successors had declared ip6_init2() as you suggest:
> >>>
> >>>   http://ftp.fr.openbsd.org/pub/OpenBSD/src/sys/netinet6/ip6_input.c
> >>>
> >>> Please, submit the patch.
> >> 
> >> OK, will do.  I noticed after that last post that ip6_init is renamed
> >> to cyg_ip6_init by one of the include files.
> >
> > Yes, I'm seeing that was entered in a merge/fix patch from Kelvin Lawson
> > in 2011. But there is also
> >
> >   include/sys/param.h:224:#define ip6_init cyg_ip6_init
> >
> >> I assume I should do the same thing for ip6_init2 if it's going to be
> >> global?
> >
> > I have doubt.  May be to change a scope of the function in ip6_input.c
> > will be enough for the case?  As for me I would not propagate the
> > definition {cyg_,}ip6_init2 in the headers.  Though, may be I wrong
> > here. I would stop on your first proposal:
> >
> >  -static void ...
> >  +void ...
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Edwards | 2 Mar 2012 00:38
Picon

array index bug in tftp_server.c

There appears to be an array index out-of-bounds problem in
tftp_server.c at line 691.  At lines 661-666 there is a for loop that
leaves i with the value CYGNUM_NET_MAX_INET_PROTOS.  Then at line 691,
'i' is used as a subscript in the experess 'server->s[i]'.  The array
s contains CYGNUM_NET_MAX_INET_PROTOS elements, so the max legal
subscript is CYGNUM_NET_MAX_INET_PROTOS-1.  But i is
CYGNUM_NET_MAX_INET_PROTOS at that point.

I have no clue what's going on in this particular code.  The use of i
as a loop index inside an outer loop that also uses i as the loop
index seems like a mistake.  I suspect that the loop at lines 661-666
should not be using i as the loop index.

   647	        for (i=0; i < CYGNUM_NET_MAX_INET_PROTOS; i++) {
   648	          if (server->s[i] && FD_ISSET(server->s[i],&readfds)) {
   649	            recv_len = sizeof(data);
   650	            from_len = sizeof(from_addr);
   651	            data_len = recvfrom(server->s[i], hdr, recv_len, 0,
   652	                                &from_addr, &from_len);
   653	            if ( data_len < 0) {
   654	              diag_printf("TFTPD [%x]: can't read request\n", p);
   655	            } else {
   656	#ifdef CYGSEM_NET_TFTPD_MULTITHREADED   
   657	              // Close the socket and post on the semaphore some
   658	              // another thread can start listening for requests. This
   659	              // is not quite right. select could of returned with more than
   660	              // one socket with data to read. Here we only deal with one of them 
   661	              for (i=0; i < CYGNUM_NET_MAX_INET_PROTOS; i++) {
   662	                if (server->s[i]) {
   663	                  close (server->s[i]);
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gary Thomas | 2 Mar 2012 00:44
Favicon

Re: array index bug in tftp_server.c

On 2012-03-01 16:38, Grant Edwards wrote:
> There appears to be an array index out-of-bounds problem in
> tftp_server.c at line 691.  At lines 661-666 there is a for loop that
> leaves i with the value CYGNUM_NET_MAX_INET_PROTOS.  Then at line 691,
> 'i' is used as a subscript in the experess 'server->s[i]'.  The array
> s contains CYGNUM_NET_MAX_INET_PROTOS elements, so the max legal
> subscript is CYGNUM_NET_MAX_INET_PROTOS-1.  But i is
> CYGNUM_NET_MAX_INET_PROTOS at that point.
>
> I have no clue what's going on in this particular code.  The use of i
> as a loop index inside an outer loop that also uses i as the loop
> index seems like a mistake.  I suspect that the loop at lines 661-666
> should not be using i as the loop index.
>
>
>     647	        for (i=0; i<  CYGNUM_NET_MAX_INET_PROTOS; i++) {
>     648	          if (server->s[i]&&  FD_ISSET(server->s[i],&readfds)) {
>     649	            recv_len = sizeof(data);
>     650	            from_len = sizeof(from_addr);
>     651	            data_len = recvfrom(server->s[i], hdr, recv_len, 0,
>     652	&from_addr,&from_len);
>     653	            if ( data_len<  0) {
>     654	              diag_printf("TFTPD [%x]: can't read request\n", p);
>     655	            } else {
>     656	#ifdef CYGSEM_NET_TFTPD_MULTITHREADED
>     657	              // Close the socket and post on the semaphore some
>     658	              // another thread can start listening for requests. This
>     659	              // is not quite right. select could of returned with more than
>     660	              // one socket with data to read. Here we only deal with one of them
>     661	              for (i=0; i<  CYGNUM_NET_MAX_INET_PROTOS; i++) {
(Continue reading)

Permalink | Reply | 1 comment |

Gmane