2008/2/26, Alban Crequy <[EMAIL PROTECTED]>:
> > I think the static variable is initialized before the DLL linkage is
> > complete.
>
> It makes sense. Do you think this problem occurs only on the simulator,
> or also on the device ? (I only tested the simulator.)
I have no idea, but I think the DLL linking code is same on both. I
recall that Martti had to fix similar stuff within Sofia SIP DLL
(initializing pthread_mutex_t structs, if I recall correctly).
> > The additional complication is that Sofia SIP DLL exports
> > an array or struct but Symbian (and Windows) DLL linkage does not
> > support them, it supports just pointers. The __declspec() magic is
> > implemented badly in the Symbian compilers (not to speak about
> > Windows), so they may end up of using the pointer to the pointer to
> > the array/struct where they should just use pointer to the
> > array/struct.
> I don't understand this additional complication. Do you have a link
> explaining this limitation on pointers and structures ? I don't think
> this complication happened in my tests until now.
Basically, we say we export
__declspec(export) int array[3];
and application says it imports
__declspec(import) int array[3];
What the application actually gets, is a variable of type
int (*_array)[3];
which is for most purposes identical to
int **_array;
When we initialize a variable with value of array with definition like
int *pointer = array;
the Symbian/Windows linker can not initialize the data segment
correctly, but the C runtime should call some generated code that
fetches the value from *array and stores it to the variable. I suspect
that the runtime fails to do so, or does it in incorrect order, or the
C compiler simply does not generate necessary code (as it is not
needed on Unix systems).
> > It seems to me that Martti just avoids static initialization with
> > pointers from DLL.
> Do you mean in other programs using the sofia-sip DLLs ? The test
> programs seems to use static initialization.
I failed to find one with quick grep. I meant something like
static tagi_t tags[] = {{ NUTAG_ANY() } ... };
but now understand that you meant that also this
tagi_t tags[] = {{ NUTAG_ANY() } ... };
breaks on Symbian.
> > > But this pattern is used a lot in sofia-sip. I don't know whether
> > > changing this pattern is the right thing to do. Maybe it is a bug
> > > in the compiler, epoc, or whatever and we should fix the real bug
> > > instead. (?)
> > >
> > > For example, see:
> > > ./libsofia-sip-ua/nua/test_nua_params.c line 59 that uses
> > > NUTAG_ANY, which is a macro expanding to symbol nutag_any from the
> > > dll.
> >
> > I think this particular example should work without problems
> > (assuming, of course, that you have fixed the IN_LIBSOFIA_SIP_UA).
> I have run a binary search to find symbols that break the linkage (e.g.
> symbols that are used with the problematic pattern). In addition to
> macros SOFIAPUBVAR/SOFIAPUBFUN that extends to the wrong __declspec(),
> I added my own macros that extends to the right __declspec(). I did
> not just fix the macro because it would be difficult to find every
> occurance of the problematic pattern in one step. So I can replace
> each problematic pattern with the pattern that works, step by step (as
> I have done in the example [1]).
>
> And when I use __declspec() correctly on nutag_any, it crashs unless I
> also use the following patch:
>
> ----->8-----------
> sofia-sip-1.12.8/libsofia-sip-ua/nua/test_nua_params.c
> @@ -56,10 +56,14 @@
> tag_typedef_t tag_b = STRTAG_TYPEDEF(b);
> #define TAG_B(s) tag_b, tag_str_v((s))
>
> - tagi_t filter[2] = {{ NUTAG_ANY() }, { TAG_END() }};
> + tagi_t filter[2] = {{ TAG_END() }, { TAG_END() }};
>
> tagi_t *lst, *result;
>
> + filter[0].t_tag = nutag_any;
> + filter[0].t_value = (tag_value_t)0;
> +
> lst = tl_list(TAG_A("X"),
> TAG_SKIP(2),
> NUTAG_URL((void *)"urn:foo"),
> ----->8-----------
>
> The patch is a hack, but show that when nutag_any is used to initialize
> a variable before the DLL linkage is complete, it crashs.
> So far, I also changed the variables _proxy_challenger and
> _registrar_challenger from ./libsofia-sip-ua/nua/test_proxy.c with a
> similar patch than above.
>
>
> > Or
> > then the __declspec() magic breaks in even worse way on Symbian than
> > on Windows.
>
>
> I don't think the problem on nutag_any is worse than the problem in
> [1]. I think it is the same problem.
>
> [1] http://discussion.forum.nokia.com/forum/showthread.php?t=127457
You are probably correct.
> Any suggestions to fix the problem ?
Check that you are linking correct runtime for your compiler.
Could you generate asm with your GCC from a C file with function using
non-zero array initializer like
#include <sofia-sip/su_tag.h>
tagi_t *tester(void)
{
tagi_t filter[2] = {{ NUTAG_ANY() }, { TAG_END() }};
return tl_adup(NULL, filter);
}
and post it? I wonder if the generated code does memcpy from data
segment, for instance, or initializes the array explicitly, and if
there is some extra code that initializes the data segment in
C++-manner, and if so, how it is supposed to be called (you might need
to call such code explicitly).
--
Pekka.Pessi mail at nokia.com
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Sofia-sip-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
