gcc and visual studio .dll...
Tarmik
Stalled on dehydra cygwin port and started to analyze what kind of
things I need to do to make gcc <-> to microsoft visual studio .dll
call link working. (gcc compiled under cygwin, dll compiled under
native $m compiler)
I was expecting a lot of problems, but I was bit suprised how easily
I've managed to compile whole tree system into visual studio.
I by myself was expecting at least some problems with gcc extensions,
like __attribute__ and so on..
cp_walk_tree_without_duplicates & statement_walker looks like working,
and debug information on "tree":s also looks like it's working. Will
start to analyze dehydra plugin in all depth.
Debugging gcc works in same manner as with ddd - you need to debug
cc1plus.exe from visual debugger.
DECL_SAVED_TREE, BIND_EXPR_BODY, cp_walk_tree_without_duplicates -
help can be found by scanning through gcc source codes ?
What for is used location_of function ?
Tarmik
Let me reply to my own question - loc_as_string converts that one to
file / source code line.
Sounds like forum is pretty much dead, or may be I'm wrong ?
Apparently 'cp_walk_tree_without_duplicates' work correctly, however
with function call 'expand_location'
I'm getting incorrect stack on return:
------------------------------------------------------------------------------------------------------------------------------------
Run-Time Check Failure #0 - The value of ESP was not properly saved
across a function call. This is usually a result of calling a
function declared with one calling convention with a function pointer
declared with a different calling convention.
------------------------------------------------------------------------------------------------------------------------------------
I have tried to use some __stdcall, __fastcall, __cdecl prefixes for
function calling, however without any result.
Also as far as I remember $m compiler uses in debug mode different
stack allocation than in release mode -
(some additional stack allocation for debug variables).
I found some intresting articles on issue:
http://www.agner.org/optimize/calling_conventions.pdf
http://en.wikipedia.org/wiki/X86_calling_conventions
http://www.codeproject.com/KB/cpp/calling_conventions_demystified.aspx
and I will dig up deeper into them. Meanwhile - may be someone on this
forum knows how to call function compiled on gcc (cplusplus1.exe)
from $m compiler (.dll).
I'm still puzzled why first function call works, may be relates to how
stack is allocated by structure. (not pointer like in first function
call case).
loc_as_string however gets correct values as far as I have checked ,
however crashes after call.
Benjamin Smedberg
> Sounds like forum is pretty much dead, or may be I'm wrong ?
No. I just don't think we have any clue what you're trying to accomplish,
which makes it hard to help.
--BDS
Tarmik
> which makes it hard to help.
1. dehydra port for cygwin (windows) environment -
currently stuck, since I did not receive any reply on another thread.
2. plugin similar to dehydra, which can obtain necessary information
on
gcc trees from gcc, preferrably using $m visual studio, since it has
superior
debugger compared for example to ddd.
3. Construct a run-time model of code, similar to gcc trees to be able
to load
source code and save it back in loseless manner. (Preserving all
comments)
Similar to CIL (C intermediate language).
4. Harmonize code run-time model to natural language - and merge
programming language and natural language into one language.
http://www.geocities.com/tapika/newlanguage_v0_2.zip
I see 1 & 2 somehow achievable, but for 3 & 4 it will be more
difficult.
But, back to earth. What about calling convention (continuing 2-nd
target)
- can anyone answer that one ?
Benjamin Smedberg
> 1. dehydra port for cygwin (windows) environment -
> currently stuck, since I did not receive any reply on another thread.
Can you explain *why* you want to do this. As we discussed in the other
thread, getting GCC plugins to work in a Windows host environment could be
very difficult because the Windows PE executable format doesn't support a
DLL importing functions from the primary executable without special export
libraries. This magic is very hard.
> 2. plugin similar to dehydra, which can obtain necessary information
> on
> gcc trees from gcc, preferrably using $m visual studio, since it has
> superior
> debugger compared for example to ddd.
The problems you would have with dehydra are the same problems you would
have with any other plugin: you have to use functions from GCC, but these
functions are not available outside of the GCC executables.
I strongly recommend that you do this hacking on Linux instead of Windows.
--BDS
Tarmik
> Tarmik wrote:
> > 1. dehydra port for cygwin (windows) environment -
> > currently stuck, since I did not receive any reply on another thread.
>
> Can you explain *why* you want to do this. As we discussed in the other
> thread, getting GCC plugins to work in a Windows host environment could be
> very difficult because the Windows PE executable format doesn't support a
> DLL importing functions from the primary executable without special export
> libraries. This magic is very hard.
If I need only dehydra for code analysis - I would switch to linux.
I have linux expirience and played around with ddd.
But steps 3 & 4 dicatates to me that I will need to have decent
debugger, since I
will need to develop infra structure similar to gcc trees.
Step 2 is only intermediate step for 3 & 4.
But weak linking is not a showstopper - there is a possibility to
extract interface
which dehydra wants from gcc, and try to cleanly rewrite/specify it.
It's also in dehydra intrest - who can guarantee you that in gcc
4.8.9
internal_error, host_integerp, warning or error function calls ?
I have already code like this in gcc:
....
plugin_set_param(21,
#ifdef ENABLE_CHECKING
(void*) &vec_assert_fail,
#else
NULL,
#endif
sizeof(void*) );
plugin_set_param(22,(void*) &warning , sizeof(void*) );
plugin_set_param(23,(void*) &warning0 , sizeof(void*) );
plugin_set_param(24,(void*) &error , sizeof(void*) );
....
and defines similar to this on DLL side:
....
typedef void (*pPointerToFunction_vec_assert_fail) (const char* op,
const char* struct_name, const char* file, unsigned int line, const
char* function);
#define vec_assert_fail \
JUMP_VIA(pPointerToFunction_vec_assert_fail,21,vec_assert_fail)
typedef void (*pPointerToFunction_warning) (int a, const char*
b, ... );
#define warning \
JUMP_VIA(pPointerToFunction_warning,22,warning)
typedef void (*pPointerToFunction_warning0) (const char* a, ... );
#define warning0 \
JUMP_VIA(pPointerToFunction_warning0,23,warning0)
typedef void (*pPointerToFunction_error) (const char* fmt, ... );
#define error \
JUMP_VIA(pPointerToFunction_error,24,error)
....
where macros expand further to:
#define JUMP_VIA(func_def,ordinal, function_name) \
((func_def) pdebug_jump(#function_name,
ordinal,__LOC__,__FUNCTION__))
#define DATA_REF_VIA(data_type,ordinal, variable_name) \
((data_type) pdebug_dataref(#variable_name,
ordinal,__LOC__,__FUNCTION__))
void* pdebug_jump(const char* pszFunctioName, int iOridinal, const
char* pszPos, const char* pszCalleeFunction);
void* pdebug_dataref(const char* pszVariableName, int iOridinal, const
char* pszPos, const char* pszCalleeFunction);
void* pdebug_jump(const char* pszFunctioName, int iOridinal, const
char* pszPos, const char* pszCalleeFunction)
{
//printf("(From: %s, func '%s')-> %s (%d) at 0x%X\n", pszPos,
pszCalleeFunction, pszFunctioName,iOridinal ,(int)
g_jumpTable_gcc_externals[iOridinal]);
return g_jumpTable_gcc_externals[iOridinal];
} //pdebug_jump
void* pdebug_dataref(const char* pszVariableName, int iOridinal, const
char* pszPos, const char* pszCalleeFunction)
{
//printf("(From: %s, func '%s')-> %s (%d) at 0x%X\n", pszPos,
pszCalleeFunction, pszVariableName,iOridinal ,(int)
g_jumpTable_gcc_externals[iOridinal]);
return g_jumpTable_gcc_externals[iOridinal];
} //pdebug_dataref
void* g_jumpTable_gcc_externals[MAX_JUMP_ENTRIES];
and originals set up function:
DLL_EXPORTED_FUNCTION void gcc_plugin_set_param(
int iArg, //[in] Argument index
void* pParamValue, //[in] pointer to argument
int iDataSize //[in] size of argument.
)
{
//Unbuffer stdout. This makes sure that any printf command
executed will
//display text right away
setvbuf(stdout,NULL,_IONBF,0);
setvbuf(stderr,NULL,_IONBF,0);
printf("-> gcc_plugin_set_param (%d, 0x%X, size=%d)\n", iArg,
(unsigned int)pParamValue,iDataSize);
if(!pParamValue)
{
printf("pParamValue is NULL, return\n");
printf("<- gcc_plugin_set_param");
return;
} //if
// Arguments specified by value.
switch(iArg)
{
case 1:
memcpy((void*) tree_contains_struct,pParamValue,sizeof
(tree_contains_struct));
printf("<- gcc_plugin_set_param");
return;
case 2:
printf("->memset");
memset((void*) tree_code_type,0,1000);
printf("<-memset");
memcpy((void*) tree_code_type,pParamValue,iDataSize);
printf("<- gcc_plugin_set_param");
return;
case 3:
memcpy((void*) tree_code_length,pParamValue,iDataSize);
printf("<- gcc_plugin_set_param");
return;
case 14:
global_namespace=(tree) pParamValue;
printf("<- gcc_plugin_set_param");
return;
default: break;
} //if
g_jumpTable_gcc_externals[iArg]=pParamValue;
printf("<- gcc_plugin_set_param");
} //gcc_plugin_set_param
Btw - currently dehydra is bound to c++ frontend, merely because you
cannot modify const tables -
like tree_code_type. If you would like to switch front end - e.g. to c
or to java - then best approach would be able
to modify those const tables. (tree_code_type, tree_code_length,
tree_contains_struct)
> I strongly recommend that you do this hacking on Linux instead of Windows.
Hmm... Intrested idea btw... I just don't have native linux os
installed on my pc computers,
but may be I could install that one.
I need anyway to learn how dehydra works, so it's irrelevant whether
I'm learning it on linux or on windows.
Related to Run-Time Check Failure of expand_location.
I wrote on gcc side following code:
void expand_location_2(source_location a, expanded_location* pOut)
{
*pOut=expand_location(a);
}
and routed pointer to .DLL:
plugin_set_param(48,(void*) &expand_location_2, sizeof(void*) );
On .DLL side I have made a wrapper:
typedef void (*pPointerToFunction_expand_location) (source_location
a,expanded_location* pOut);
expanded_location expand_location(source_location a)
{
expanded_location exl;
JUMP_VIA(pPointerToFunction_expand_location,48,expanded_location)
(a,&exl);
return exl;
}
After this expand_location seems to be working correctly with
microsoft compiler.
This means that:
expanded_location expand_location (source_location a);
this function prototype causes some calling convention problem between
$m compiler and gcc compiler
but function:
void expand_location (source_location a,expanded_location* pOut);
works fine. I suspect that pointers are allocated in same manner on
stack, but not structures.
One step further, now I can see all locations where particular code
resides.
Now I will analyze statement_walker bit deeper.
Benjamin Smedberg
> On Nov 21, 5:41 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
>> Tarmik wrote:
>>> 1. dehydra port for cygwin (windows) environment -
>>> currently stuck, since I did not receive any reply on another thread.
>> Can you explain *why* you want to do this. As we discussed in the other
>> thread, getting GCC plugins to work in a Windows host environment could be
>> very difficult because the Windows PE executable format doesn't support a
>> DLL importing functions from the primary executable without special export
>> libraries. This magic is very hard.
>
> If I need only dehydra for code analysis - I would switch to linux.
> I have linux expirience and played around with ddd.
> But steps 3 & 4 dicatates to me that I will need to have decent
> debugger, since I
> will need to develop infra structure similar to gcc trees.
> Step 2 is only intermediate step for 3 & 4.
gdb has some problems, no doubt, but it's still a fairly effective debugger
if you know how to use it... and especially if you compile your code with
-g3 so that GDB can expand macros.
> But weak linking is not a showstopper - there is a possibility to
> extract interface
> which dehydra wants from gcc, and try to cleanly rewrite/specify it.
> It's also in dehydra intrest - who can guarantee you that in gcc
> 4.8.9
> internal_error, host_integerp, warning or error function calls ?
We have no desire to have a stable interface between GCC and the plugin: we
hope to eventually provide a relatively stable interface at the JS level,
but we are still bound by the actual implementation of GCC trees and internals.
A stable interface would slow down GCC and plugin development in
unacceptable ways: we're more interested in tracking GCC development than
trying to make it stable.
> Btw - currently dehydra is bound to c++ frontend, merely because you
> cannot modify const tables -
> like tree_code_type. If you would like to switch front end - e.g. to c
> or to java - then best approach would be able
> to modify those const tables. (tree_code_type, tree_code_length,
> tree_contains_struct)
Why? It seems easier to simply compile a different dehydra plugin for the C
frontend using its definitions, than attempt to build a single plugin to
work with different compilers.
>> I strongly recommend that you do this hacking on Linux instead of Windows..
>
> Hmm... Intrested idea btw... I just don't have native linux os
> installed on my pc computers,
> but may be I could install that one.
>
> I need anyway to learn how dehydra works, so it's irrelevant whether
> I'm learning it on linux or on windows.
The fact that dehydra actually works on Linux and probably won't work on
Windows should be a pretty compelling argument for installing VMWare and
trying this on Linux ;-)
We may even have a Linux VM image that is set up to do analysis already; I'm
not sure.
--BDS
Jean-Marc Desperrier
> [...] getting GCC plugins to work in a Windows host environment could be
> very difficult because the Windows PE executable format doesn't support a
> DLL importing functions from the primary executable without special export
> libraries. This magic is very hard.
It requires some work, but I don't think it deserves to be described as
very hard.
*If* you have a list of the function your plug-in requires, then you can
automate the process to mark them as exported when compiling the primary
executable *and* create the library the plug-in requires.
When the plug-in dll is loaded, the windows loader will see the primary
executable is already in the memory space and resolve the function calls.
In fact, with GCC if you change the default for the visibility attribute
of function to false, you will get the same situation as under Windows
(almost, there's still the fact the windows linker requires an export
library, but creating that library from the exe/dll can be automated
with proper tools).