[OLSR-users] Mips-Processor: Plugins will SEGV

Sven-Ola Tuecke (spam-protected)
Mon Nov 1 12:15:36 CET 2004


Hi Andreas,

the Plugin-changes in olsrd-0.4.8 will not affect this issue - but to ensure 
normal functioning, my further testing will be based on 0.4.7 from now on :)

Regards, Sven-Ola

----- Original Message ----- 
From: "Andreas Tønnesen" <(spam-protected)>
To: <(spam-protected)>
Cc: <(spam-protected)>
Sent: Monday, November 01, 2004 11:51 AM
Subject: Re: [OLSR-users] Mips-Processor: Plugins will SEGV


> Hi Sven,
>
> First of all - I highly recommend not using the CVS version for plugin
> testing. There has been a lot of olsrd internal changes and most of the
> plugins require quite some rewrites to work with this version(this will
> ofcause be fixed before the next release).
>
> This issue has been discussed before:
> http://www.olsr.org/pipermail/olsr-users/2004-October/000233.html
> But I don't think any conclusions were drawn there... But you could check
> out the mips-i vs. mips-ii issue mentioned there.
> I guess it could be something uclibc related. I will put it on my todo
> list - but it will probably be some time before I can look into it.
>
> Regarding the ampersand in the function pinter assignments I believe the &
> is optional in this case. To me it looks better using it - but as with
> most such things I guess it's a matter of taste :)
>
> - Andreas
>
>> Hi,
>>
>> recently, I've read the posting about the dyn_gw on this list. This 
>> sounds
>> promising, so I tried to run that plugin on my WRT54g. But: loading the
>> plugin will stop olsrd from running with a SEGV message. Seems to be some
>> traditional bug in olsrd. Further investigation reveals:
>>
>> - Plugin runs OK on Intel (both Win and Linux)
>> - Plugin fails miserably on Mips (both WRT54g and Meshcube)
>> - Plugin fails both for 0.4.7 and for 0.4.8 (cvs version 30-oct)
>>
>> Further debugging will help here, so I've patched
>> lib/dyn_gw/src/olsrd_plugin.c:
>>
>> *** Snippet from olsrd-0.4.8-cvs-2004-10-30 ***
>> int
>> register_olsr_data(struct olsr_plugin_data *data)
>> {
>>   /* IPversion */
>> fprintf(stderr, "register_olsr_data(%p)\n", data);
>>   ipversion = data->ipversion;
>> fprintf(stderr, "ipversion(%d)\n", ipversion);
>>   /* Main address */
>>   main_addr = data->main_addr;
>> fprintf(stderr, "main_addr(%d)\n", main_addr);
>>
>>   /* Multi-purpose function */
>> fprintf(stderr, "olsr_plugin_io gleich!!!\n");
>> fprintf(stderr, "1olsr_plugin_io(%d)\n", data->olsr_plugin_io);
>>   olsr_plugin_io = data->olsr_plugin_io;
>> fprintf(stderr, "2olsr_plugin_io(%d)\n", olsr_plugin_io);
>>
>> *** /Snippet ***
>>
>> This will output the following if started on MIPS:
>>
>> ---------- Plugin loader ----------
>> Library: olsrd_dyn_gw.so.0.1
>> OLSRD dynamic gateway plugin 0.1 by Andreas Tønnesen
>> Checking plugin interface version.... 1 - OK
>> Trying to fetch plugin IO function....OK
>> Trying to fetch register function....OK
>> Running registration function...
>> register_olsr_data(0x7fff6c50)
>> ipversion(2)
>> main_addr(268449888)
>> olsr_plugin_io gleich!!!
>> 1olsr_plugin_io(4267792)
>> Segmentation fault
>>
>> I'am fiddling a bit with variable storage classes, and have some success
>> with adding "static" and the " = 0" initializer in the *.h where
>> "olsrd_plugin_io" is defined. However, this is not the only function
>> pointer
>> used, so it's segfault again. Anybody knows, if this is a gcc cross
>> compiler
>> bug? Or just something with DS!=SS so one have to use compiler overwrites
>> "CALLBACK global do not assume Data and Stack on same segement" here?
>> Another comment: Is there a superfluous ampersand in the "olsrd_plugin_io
>> =
>> &whatever_function;"? My C++/ASM knowledge is bailing out here, 
>> especially
>> the parentesis jungle used to define function pointers in C/C++ alway
>> confuses me...
>>
>> Regards, Sven-Ola
>>
>> _______________________________________________
>> olsr-users mailing list
>> (spam-protected)
>> https://www.olsr.org/mailman/listinfo/olsr-users
>>
>
>
> ---------
> Andreas Tønnesen
> http://www.olsr.org
> 




More information about the Olsr-users mailing list