[ECOS] Free BSD ioctl problem (Renesas EDOSK2674)

[ECOS] Free BSD ioctl problem (Renesas EDOSK2674)

[Uwe Kindler]

Hello,

i tried to get the FreeBSD network stack working for Renesas EDOSK2674.
Network support for EDOSK2674 Redboot works well but when tried to run the
networking tests for an eCos configuration with FreeBSD stack, I recived the
following messages during initialisation (init_all_network_interfaces).:

...
       hw_addr: ff:ff:ff:ff:ff:ff
     client IP: 130.100.80.12
         my IP: 130.100.80.12
     server IP: 130.100.80.1
    gateway IP: 130.100.80.1
  options:
        subnet mask: 255.255.255.0
       IP broadcast: 130.100.80.255
            gateway: 130.100.80.1
SIOCIFADDR: Operation not supported
Network initialization failed for eth0.

Now I started debugging and found that the problem is caused by the folowing
function in file io.cxx:

__externC int ioctl( int fd, CYG_ADDRWORD com, CYG_ADDRWORD data )
{
    ...
}

The function is declared in various header files (i.e. ioctl.h) in the
following way:

int ioctl __P((int, unsigned long, ...));

Single stepping the assembler code before the ioctl function call was the
solution. The function arguments where pushed onto stack because of a
function declaration with variable argument list. But the function itself
does not have a variable argument list and expected the arguments in
registers er0, er1, er2 - so it simply received the wrong arguments.

Now I changed the function declaration this way:

int ioctl __P((int, unsigned long, unsigned lon));

Now the network initialisation works well and I could successfull complete
the ping_test for the FreeBSD network stack.

So my question is: Why differs the declaration of ioctl function from
definition in file io.cxx and did I found the right solution or do I have to
chnge something different.

Thank you very much and regards, Uwe


eCos port for Renesas H8S family
http://www.htwm.de/ukindler/ecos


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Free BSD ioctl problem (Renesas EDOSK2674)

[Andrew Lunn]

On Fri, Jun 04, 2004 at 07:50:44PM +0200, Uwe Kindler wrote:
> Hello,
> 
> i tried to get the FreeBSD network stack working for Renesas EDOSK2674.
> Network support for EDOSK2674 Redboot works well but when tried to run the
> networking tests for an eCos configuration with FreeBSD stack, I recived the
> following messages during initialisation (init_all_network_interfaces).:
> 
> ...
>        hw_addr: ff:ff:ff:ff:ff:ff
                  ^^^^^^^^^^^^^^^^^ 

You should probably take a look at this. Using the broadcast address
is not good.

        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

Re: [ECOS] Free BSD ioctl problem (Renesas EDOSK2674)

[Uwe Kindler]

Hello Andrew,

> > ...
> >        hw_addr: ff:ff:ff:ff:ff:ff
>                   ^^^^^^^^^^^^^^^^^
>
> You should probably take a look at this. Using the broadcast address
> is not good.
>
>         Andrew
>

you should propably read my complete posting ;o) - i wrote the problem is
the ioctl function. But I will try to explain it more clear:

During initialisation of network in init_all_network_interfaces the function
build_bootp_record is called which sets up the bootp_record.
I do not use a hw boradcast address - I use the mac address stored in eeprom
of my Renesas EDOSK2674. But the function build_bootp_record does not fill
the bootp_record correctly. Why? Because it calls the function ioctl in
order to get the hardware address. This is the call in build_bootp_record
for the hardware mac address:

if (s >= 0) {
        strcpy(ifr.ifr_name, if_name);
        if (ioctl(s, SIOCGIFHWADDR, &ifr) >= 0) {
            bcopy(ifr.ifr_hwaddr.sa_data, bp->bp_chaddr, bp->bp_hlen);
        }

The ioctl function does not work correctly because the declaration in
various header files (i.e. ioctl.h) differs from the definition in io.cxx.

This is the declaration with variable argument list (i.e. in ioctl.h):

int ioctl __P((int, unsigned long, ...));

This is the definition in io.cxx with fixed argument list:

__externC int ioctl( int fd, CYG_ADDRWORD com, CYG_ADDRWORD data )
{
    ...
}

When the function is called then the function arguments where pushed onto
the stack because a variable argument list is expected because of the
declaration of the ioctl function. This is how the assembler code looks like
before the ioctl function call:

...
mov.l er2, @-er7                       // push arg3 on stack
mov.l #0xc0306964, er2
mov.l er2, @-er7                       // push arg2 on stack
mov.l @(oxffec:16,er6), er0       // move arg1 in er0
jsr @0x44a6a8:24                     // call ioctl function

The register er7 is the stack pointer. So the arguments 2 and 3 are pushed
onto stack and argument 1 is in register er0. And this is the assembler code
in the function ioctl immediately after the jsr instruction above is
executed:

mov.l er6, @-er7                   // save frame pointer
mov.l er7,er6
add.l #0xffffffe4,er7
mov.l er0,@(0xfffc:16,er6)     // get arg 1 from er0
mov.l er1,@(0xfff8:16,er6)     // get arg 2 from er1
mov.l er2,@(0xfff4:16,er6)     // get arg 3 from er2

So you can see, the function sets up the stack and then copies the function
arguments from the registers er0, er1 and er2 onto stack. But because of the
different function declaration the registers er0, er1 and er2 do not contain
the expected values. Now I changed the function declaration in a way that it
matches the definition:

Changed function declaration:

int ioctl __P((int, unsigned long, unsigned long));

Now the  assembler code before the function call of ioctl function looks
this way:

...
mov.l er6, er2                            // store arg 3 in er2
add.l #0xffffffb0, er2
mov.l @(0xfff8:16,er6), er1       // store arg 2 in er1
mov.l er2,er0                             // store arg 1 in er0
jsr @0x44a6a8:24                     // call ioctl function

Now the function arguments are stored where the ioctl function expects them
to be an I get the following output:
...
       flags: 0x0
       hw_addr: 00:00:87:d6:34:b9
     client IP: 192.168.101.152

Now my hw address is set properly and init_all_network_interfaces works like
expected.

So I repeat my question: Why differs the function declaration from function
definition and what should I do in order to fix this problem?

Thank you very much and regards,

Uwe

eCos port for Renesas H8S family
http://www.htwm.de/ukindler/ecos



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Free BSD ioctl problem (Renesas EDOSK2674)

[Andrew Lunn]

On Sat, Jun 05, 2004 at 10:49:12AM +0200, Uwe Kindler wrote:
> Hello Andrew,
> 
> > > ...
> > >        hw_addr: ff:ff:ff:ff:ff:ff
> >                   ^^^^^^^^^^^^^^^^^
> >
> > You should probably take a look at this. Using the broadcast address
> > is not good.
> >
> >         Andrew
> >
> 
> you should propably read my complete posting ;o) 

Actually i did read the complist posting, but i did not have time to
look at the IOCTL issue. I did notice that the MAC addresses was wrong
and assumed that was a seperate problem. I assumed your problem was
with the ioctl error:

SIOCIFADDR: Operation not supported.

I had failed to put 2 and 2 together in that the MAC address itself is
retrived with an ioctl call....

- i wrote the problem is
> the ioctl function. But I will try to explain it more clear:

I would like to complement you on the quality of your bug report. I
get fed up of emails saying that my program crashes, please tell me
what i am doing wrong. Its great to see this much detail and people on
this list are much more likely to help you when you give some real
details to work from.

So the problem boils down to that the caller is using a different
calling convention than the callee. This is a result of the function
declaration being different than the definition.

[snip]


> Changed function declaration:
> 
> int ioctl __P((int, unsigned long, unsigned long));

This fixes your problem, but unfortunetly, its not the correct
solution. The relevant part of the POSIX standard is:

http://www.opengroup.org/onlinepubs/009695399/toc.htm

NAME

    ioctl - control a STREAMS device (STREAMS)

SYNOPSIS

    [XSR] #include <stropts.h>

    int ioctl(int fildes, int request, ... /* arg */);

So in fact ... is correct, and making the 3rd argument an unsigned
long is wrong.

> So I repeat my question: Why differs the function declaration from function
> definition and what should I do in order to fix this problem?

What should you do to fix the problem?

Thats an interesting question....

http://www.gnu.org/software/libc/manual/html_node/Why-Variadic.html#Why%20Variadic

The last paragraph says:

        Some functions such as open take a fixed set of arguments, but
        occasionally ignore the last few. Strict adherence to ISO C
        requires these functions to be defined as variadic; in
        practice, however, the GNU C compiler and most other C
        compilers let you define such a function to take a fixed set
        of arguments--the most it can ever use--and then only declare
        the function as variadic (or not declare its arguments at
        all!).

That describes what is going on here. ioctl is defined to take three
parameters, the maximum it uses and the declaration is variadic.

So i would say you have a compiler bug. The fact that this code works
correctly on i386, mips, ppc, arm etc, also suggests its an H8S
compiler bug. 

I suggest you make a simple example program that demostrats the bug
and post a bug report to the gcc mailing list and maybe the gnuh8
list.

I hope this helps,

          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

Re: [ECOS] Free BSD ioctl problem (Renesas EDOSK2674)

[Uwe Kindler]

Hello Andrew,

in your last mail regarding the IOCTL problem you suggested the following to
me:

> The last paragraph says:
>
>         Some functions such as open take a fixed set of arguments, but
>         occasionally ignore the last few. Strict adherence to ISO C
>         requires these functions to be defined as variadic; in
>         practice, however, the GNU C compiler and most other C
>         compilers let you define such a function to take a fixed set
>         of arguments--the most it can ever use--and then only declare
>         the function as variadic (or not declare its arguments at
>         all!).
>
> That describes what is going on here. ioctl is defined to take three
> parameters, the maximum it uses and the declaration is variadic.
>
> So i would say you have a compiler bug. The fact that this code works
> correctly on i386, mips, ppc, arm etc, also suggests its an H8S
> compiler bug.
>
> I suggest you make a simple example program that demostrats the bug
> and post a bug report to the gcc mailing list and maybe the gnuh8
> list.

I did what you have suggested to and received the following answer from GNU
support:

//--------------------------------------------------------------------------
-
"I think the statments made in the above link regarding variadic functions
are plainly wrong. It may work for sometimes for some targets but definately
not for all targets. The reason is the compiler may and can pass arguments
differently depending on the prototype and especially for varadic
functions."

Both the declaration and definition should agree mixing them isn't going to
work."

Please refer following link,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16000

Regards,
GNU Support.
//-----------------------------------------------------------------------

So maybe it is necessary now to fix the function ioctl in io.cxx to take a
variable number of arguments.

Regards, Uwe





-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Free BSD ioctl problem (Renesas EDOSK2674)

[Andrew Lunn]

> I did what you have suggested to and received the following answer from GNU
> support:
> 
> //--------------------------------------------------------------------------
> -
> "I think the statments made in the above link regarding variadic functions
> are plainly wrong. It may work for sometimes for some targets but definately
> not for all targets. The reason is the compiler may and can pass arguments
> differently depending on the prototype and especially for varadic
> functions."
> 
> Both the declaration and definition should agree mixing them isn't going to
> work."
> 
> Please refer following link,
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16000
> 
> Regards,
> GNU Support.
> //-----------------------------------------------------------------------
> 
> So maybe it is necessary now to fix the function ioctl in io.cxx to take a
> variable number of arguments.

Its interesting GNU are saying there own documentation is wrong,
especially when this actually works for most targets. Let me do some
more checking.

        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

Re: [ECOS] Free BSD ioctl problem (Renesas EDOSK2674)

[Andrew Lunn]

Well it seems that no standard says this this should work. In practice
it does work for 95% of the gcc backends, with the H8 being the 5%
that does not.

> So maybe it is necessary now to fix the function ioctl in io.cxx to take a
> variable number of arguments.

Unfortunately, its not that simple...

~/eCos/anoncvs/packages$ find . -name "*.h" | xargs grep " \.\.\..)" | grep -v -e printf -e scanf| wc
     49     334    4511

If we are going to do this, we should do it properly. So you need to
check these 49 uses of ... and see if they also need changing to use
varidic and va_arg.

        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

Re: [ECOS] Free BSD ioctl problem (Renesas EDOSK2674)

[Uwe Kindler]

Hello Andrew,



> Well it seems that no standard says this this should work. In practice
> it does work for 95% of the gcc backends, with the H8 being the 5%
> that does not.
>
> > So maybe it is necessary now to fix the function ioctl in io.cxx to take
a
> > variable number of arguments.
>
> Unfortunately, its not that simple...
>
> ~/eCos/anoncvs/packages$ find . -name "*.h" | xargs grep " \.\.\..)" |
grep -v -e printf -e scanf| wc
>      49     334    4511
>
> If we are going to do this, we should do it properly. So you need to
> check these 49 uses of ... and see if they also need changing to use
> varidic and va_arg.
>
>         Andrew
>

Okay, I will try to check all 49 uses of ... within the next days.

Regards, Uwe


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Free BSD ioctl problem (Renesas EDOSK2674)

[Uwe Kindler]

Hello Andrew,

just for your information. I have mailed the H8S IOCTL call problem we have
talked about to www.kpitgnutools.com and received the following answer.

------------------------------------------------------
Hi,

Thank you for using the GNUH8 tool chain.
We accept that gcc does not behave as per the documentation in
http://www.gnu.org/software/libc/manual/html_node/Why-Variadic.html#Why%20Va
riadic
We will file a bug report on this to the GCC mailing list.

Regards,
GNU Support.
----------------------------------------------------------

So there is another issue you should keep in mind when offering H8S support
:o(.
As a workaround for my H8S port of eCos I think about making the ioctl
function definition in io.cxx variadic so that it matches the declaration.

Regards, Uwe

eCos port for Renesas H8S family
http://www.htwm.de/ukindler/ecos


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss