[Click] Error compiling my package in Click for kernel level

Harkeerat Bedi hsbedi at memphis.edu
Tue Feb 7 02:22:37 EST 2012


Thank you Cliff for your suggestions and explanations. They were very
helpful.

I ended up removing the static member variables which I was using from my
code. I did this mainly because, my package contains some external C++
files which do not contain an element. These files instead hold C++ classes
which had these static member variables. They were of non-primitive types. I
was not sure if I could have used static_initialize() function in this
scenario. Was it possible?

Now after removing them, my package compiles and runs in kernel level. It
runs as expected for a few seconds, and then it hangs. Since I am running
it in kernel level, the whole system crashes. I am currently running Click
on a VM. I have Click version 2.0.1 from git-hub installed (both user level
and patchless kernel level) on an Ubuntu 10.04 LTS system. My kernel is
2.6.32-38-generic (i686) and gcc version is 4.4.3 (Ubuntu 4.4.3-4ubuntu5).

I would like debug this issue. I do on get any helpful information using
"dmesg".

I tried to debug it using gdb using the following commands:
     sudo gdb /usr/local/click/sbin/click-install
     run myconfig.click

And I get the following output:

     Starting program: /usr/local/click/sbin/click-install myconfig.click
     [Thread debugging using libthread_db enabled]

     Program exited normally.
     (gdb)

The above terminates the gdb session, but not the Click configuration which
still remains active and running. However, after a while the kernel/system
crashes. This crash happens even if I don't use the gdb debugger.

Can you suggest how I can try to debug this?

I am able to run my package (and debug it using gdb) in user level and do
not experience any issues.

Thank you once again.

Regards,
Harkeerat Bedi
University of Memphis


On Mon, Feb 6, 2012 at 1:11 AM, Cliff Frey <cliff at meraki.com> wrote:

> responses inline
>
> On Sun, Feb 5, 2012 at 10:41 PM, Harkeerat Bedi <hsbedi at memphis.edu>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
>
>


More information about the click mailing list