Re: Error compiling my package in Click for kernel level
Cliff Frey <[email protected]>
| Newsgroups | gmane.network.routing.click |
|---|---|
| Message-ID | <CAFtVOq=XhWWZ+GQEc1c_4y_bteVztVi8yvEGUKUVF8dAwQT5Vg@mail.gmail.com> |
responses inline On Sun, Feb 5, 2012 at 10:41 PM, Harkeerat Bedi <[email protected]> wrote: > After removing floating point arithmetic, now the following errors remain > (dmesg output): > > [ 4184.551295] click: starting router thread pid 9889 (f3d7f6c0) > [ 4184.569707] myelementpackage: Unknown symbol __dso_handle > [ 4184.572406] myelementpackage: Unknown symbol __cxa_atexit > [ 4197.961612] click: stopping router thread pid 9889 > [ 4197.961637] click module exiting > > Can you kindly suggest how I can fix these errors? If they are due to my > use of static member variables, can we handle these errors without removing > them? > You may need to make your static/global variables be of simple type (or pointers to classes), and then use a static_initalize() function to allocate and assign values to those static/global variables. > Also, in the #define written above, if I cast the values of A and B with > int64_t, like: > #define fixedpt_xdiv(A,B) (int32_t)(((int64_t)A << 8) / (int64_t)B) > > I get the following additional error: > [ 4475.103019] myelementpackage: Unknown symbol __divdi3 > > Can you suggest why casting with int64_t causes such an error? > This is causing gcc to assume that libgcc is available, and it is not in the kernel. You can use the functions in click/include/click/bigint.hh to perform 64/32 bit division if you need it. > > On a side note, I was interested to see if I could get similar errors if I > added floating point arithmetic in the sample package provided by Click in > ...DIR/etc/samplepackage/ directory. > I added the following code in the initialize() definition in sampleelt.cc: > > int > SamplePackageElement::initialize(ErrorHandler *errh) > { > errh->message("Successfully linked with package!"); > float temp; > float temp1 = 121.1211; > float temp2 = 345234.32423; > temp = temp2 / temp1; > click_chatter("temp: %d", (int64_t) temp); > return 0; > } > > However, the element ran successfully in kernel level, with the following > output in dmesg: > > [14044.407445] click: starting router thread pid 19173 (f4026780) > [14044.412844] test.click:3: While initializing 'test :: > SamplePackageElement': > [14044.412848] Successfully linked with package! > [14044.412853] chatter: temp: 2850 > [14046.287880] click: stopping router thread pid 19173 > [14046.287897] click module exiting > > Can you kindly suggest why we did not observe any errors for using floating > point arithmetic in this case? > That code is completely inlined/executed at compile time. Try marking one of the variables as "volatile" or make one of them depend on a runtime quantity, and that code will fail to load as well. Cliff