[Click] 64-bit platform query

Eddie Kohler kohler at cs.ucla.edu
Thu Jun 15 21:04:05 EDT 2006 

Hi Jonathan,

I'm not sure how up-to-date the grid elements are.  I've checked in some 
updates to the grid code, however.

> When I add support for grids, I get the following
> error:
> 
>   CXX ../elements/grid/dsdvroutetable.cc
> ../elements/grid/dsdvroutetable.cc: In member function
> 'void
> DSDVRouteTable::build_and_tx_ad(Vector<DSDVRouteTable::RTEntry>&)':
> ../elements/grid/dsdvroutetable.cc:1500: error: cast
> from 'unsigned char*' to 'unsigned int' loses
> precision
> ../elements/grid/dsdvroutetable.cc:1515: error: cast
> from 'grid_hdr*' to 'unsigned int' loses precision
> 
> These lines are macro calls to ASSERT_ALIGNED, which
> is defined in grid.hh as follows: 
> 
> // packet data should be 4 byte aligned
> #define ASSERT_ALIGNED(p) assert(((unsigned int)(p) %
> 4) == 0)
>                                                       
>                          
> First off, will the assumption of 4 byte alignment
> hold true on 64-bit platforms?

Yes.  This assertion refers to packet formats, which need to be 4-byte aligned 
as that's the network format.  The problem was that the formats themselves 
used types like 'unsigned int' that might turn into 64-bit types.  I've 
updated this.

> A temporary workaround (just casting it to an unsigned
> long int) gets past that problem. However, a few files
> later, I run into a much bigger problem, also in the
> grid code:
> 
>   CXX ../elements/grid/gridheaderinfo.cc
> ../elements/grid/gridheaderinfo.cc:61: warning:
> invalid access to non-static data member
> 'grid_hdr::version' of NULL object
> ../elements/grid/gridheaderinfo.cc:61: warning:
> (perhaps the 'offsetof' macro was used incorrectly)
> ../elements/grid/gridheaderinfo.cc:62: warning:
> invalid access to non-static data member
> 'grid_hdr::type' of NULL object
> ../elements/grid/gridheaderinfo.cc:62: warning:
> (perhaps the 'offsetof' macro was used incorrectly)
> ../elements/grid/gridheaderinfo.cc:63: warning:
> invalid access to non-static data member
> 'grid_hdr::ip' of NULL object
> ../elements/grid/gridheaderinfo.cc:63: warning:
> (perhaps the 'offsetof' macro was used incorrectly)
> ../elements/grid/gridheaderinfo.cc:64: warning:
> invalid access to non-static data member
> 'grid_hdr::tx_ip' of NULL object
> ../elements/grid/gridheaderinfo.cc:64: warning:
> (perhaps the 'offsetof' macro was used incorrectly)
> ../elements/grid/gridheaderinfo.cc:65: warning:
> invalid access to non-static data member
> 'grid_hdr::total_len' of NULL object
> ../elements/grid/gridheaderinfo.cc:65: warning:
> (perhaps the 'offsetof' macro was used incorrectly)
> ../elements/grid/gridheaderinfo.cc:67: warning:
> invalid access to non-static data member
> 'grid_nbr_encap::dst_ip' of NULL object
> ../elements/grid/gridheaderinfo.cc:67: warning:
> (perhaps the 'offsetof' macro was used incorrectly)
> ../elements/grid/gridheaderinfo.cc:69: warning:
> invalid access to non-static data member
> 'grid_loc_query::dst_ip' of NULL object
> ../elements/grid/gridheaderinfo.cc:69: warning:
> (perhaps the 'offsetof' macro was used incorrectly)
> ../elements/grid/gridheaderinfo.cc: In function
> 'String ghi_read_handler(Element*, void*)':
> ../elements/grid/gridheaderinfo.cc:98: error: cast
> from 'void*' to 'int' loses precision
> 
> The error itself is again a 32-bit vs. 64-bit issue,
> but some of the warnings indicate that there may be
> other cleanups required.

Error fixed!  The warnings are hard to fix.

> The test elements also hace a 32-bit-ism:
> 
>   CXX ../elements/test/upstreamnotifier.cc
> ../elements/test/upstreamnotifier.cc: In function 'int
> write_param(const String&, Element*, void*,
> ErrorHandler*)':
> ../elements/test/upstreamnotifier.cc:87: error: cast
> from 'void*' to 'int' loses precision

Fixed!

> Finaly, these two warnings don't look serious to me,
> but I'd value a second opinion simply because of the
> above problems:
> 
>   CXX ../elements/ip/ipratemon.cc
> ../elements/ip/ipratemon.cc: In destructor
> 'IPRateMonitor::Stats::~Stats()':
> ../elements/ip/ipratemon.cc:249: warning: overflow in
> implicit constant conversion
> ../elements/ip/ipratemon.cc:281: warning: overflow in
> implicit constant conversion

Not a problem, I think.

Eddie


> 
> Thanks,
> 
> Jonathan Day
> 
> --- Adam Greenhalgh <a.greenhalgh at cs.ucl.ac.uk> wrote:
> 
>> We've had a number of problems with 64bit click on
>> an AMD 64, I've
>> posted some fixes to the list and we now seem to
>> have it running ok
>> now. Where we are seeing an issue is the polling
>> driver for the e1000,
>> I'm not totally sure whether the driver or the click
>> linux integration
>> or both are at fault. If I get a free moment, I'll
>> look further, but
>> life is a bit manic at the moment.
>>
>> Adam
>>
>> On 6/15/06, Jonathan Day <imipak at yahoo.com> wrote:
>>> Hi,
>>>
>>> Yes, I'm using 1.5. I'm downloading the CVS files
>> as I
>>> type, to see if those work better. I guess I
>> should
>>> specify a little more precisely. I'm compiling on
>> a
>>> Broadcom BCM1250 (a dual-core system based on the
>> SB1,
>>> which is a processor based on version 0.95 of the
>>> 64bit MIPS specification).
>>>
>>> This is a notoriously evil platform, so it is hard
>> to
>>> determine which problems lie in the Click code and
>>> which lie in a CPU that surely must constitute
>> cruel
>>> and unusual punishment toards programmers.
>>>
>>> I am also going to do some tests to see if it is a
>>> problem in the options I selected, so I can give a
>>> more useful report on what the problem is, now
>> that
>>> it's clear that 64-bit platforms are working.
>>>
>>> Jonathan
>>>
>>> --- Bart Braem <bart.braem at ua.ac.be> wrote:
>>>
>>>> On Thursday 15 June 2006 01:28, Jonathan Day
>> wrote:
>>>>> Does anyone have a set of patches to make
>> Click
>>>> 64-bit
>>>>> clean? If not, does anyone have any
>> suggestions on
>>>> how
>>>>> I could fix the type length issues without
>>>> breaking
>>>>> any of the requirements of Click?
>>>> Are you sure you are using the latest version of
>>>> Click (at least 1.5 or even
>>>> better CVS)? There have been reports on this
>> list of
>>>> Click running on 64 bit
>>>> and there are certainly fixes in the Click
>> source...
>>>> Bart
>>>> --
>>>> Bart Braem
>>>> PATS research group
>>>> Dept. of Mathematics and Computer Sciences
>>>> University of Antwerp
>>>> G2.36, Building G
>>>> Middelheimlaan 1
>>>> 2020 Antwerpen, Belgium
>>>> Phone: +32 (0)3 265.35.19.
>>>> Fax: +32 (0)3 265.37.77.
>>>> Web: www.pats.ua.ac.be
>> _______________________________________________
>>>> click mailing list
>>>> click at amsterdam.lcs.mit.edu
>>>>
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam
>> protection around
>>> http://mail.yahoo.com
>>> _______________________________________________
>>> click mailing list
>>> click at amsterdam.lcs.mit.edu
>>>
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click

More information about the click mailing list