[Click] 64-bit platform query

Jonathan Day imipak at yahoo.com
Thu Jun 15 17:23:06 EDT 2006


Hi,

Thanks for the heads-up. Ok, I can now report that
Click from CVS will compile cleanly (ignoring probably
meaningless warnings) if the default options are used,
so it looks like the show-stoppers for me have been
fixed. The same is true for most of the modules I've
tried.

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? This determines the
best method of fixing this. If the assumption is
correct, then the "unsigned int" needs to be replaced
with something generic that is #defined to be a 32-bit
type on 32-bit platforms or a 64-bit type on 64-bit
platforms.

(If it isn't correct, then it would be easier to have
multiple versions of this line, one for 32-bit and one
for 64-bit, as that produces the cleanest solution.)

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.

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

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

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 


More information about the click mailing list