Reverse Engineering with Macros

[KevinH]

When attempting to import source code, EA only sees the original files. If I cancel the import, modify a header file and redo an import, the new change is not seen !

I must close EA and restart it in order to see the change.

[Eve]

Hi Kevin,

EA always loads the files as the currently appear on disk when doing reverse engineering.  So your problem is very strange and I would need more information to even attempt to track this down.

(Also, the subject of this thread seems to imply that you might need to look at how EA handles preprocessor macros. http://www.sparxsystems.com/EAUserGuide/index.html?languagemacros.htm)

[KevinH]

Yes indeed I am trying to get macros recognized during a source code import. I will get back to you on the macros...

Concerning the source code import : You are absolutely right about the source code being loaded at each import... BUT this is difficult to know since the output window is not refreshed at each import AND no timestamp is associated with the parsing errors. I assumed that the output window was refreshed at each import and that the error messages I was getting were current. Also, a successful import results in NO output. ()

Thank you for your prompt reply.


:-/

[sl@sh]

I am posting to this thread although the problem I have is a bit different to the original one: when reverse engeneering a class that uses Macros for it's methods only, EA didn't appear to store away the Macros as it should, according to the description given in http://www.sparxsystems.com/EAUserGuide/index.html?languagemacros.htm

After some investigation I found out that in those cases the tagged values were not created by EA, the macro was the very first symbol of the method definition. So, a definition like this:

Code: [Select]

MY_DECL void foo();
would be generated into a method without tagged value. A definition like this:

Code: [Select]

virtual MY_DECL void foo();
or this:

Code: [Select]

static MY_DECL void foo();
or this:

Code: [Select]

void MY_DECL foo();
would be generated into a method with tagged value.

Please note that all declaration formats above are valid, even the first one. So EA should be able to read and correctly recognize (and tag!) it.

Moreover, in case you try to tag a __declspec onto a specific variable:

Code: [Select]

MY_DECL class X {} my_x; // __declspec applies to my_x, not class X!, it is not possible to simply move the MY_DECL symbol right in front of the class name, because that would change the syntax! If you look at this code:

Code: [Select]

class MY_DECL X {} my_x;the __declspec would apply to the class X, not the variable my_x;

P.S.:
I now found that in two cases the way EA treats __declspec Macro definitions actually creates erroneous code (as in: does not compile correctly!):

1. When a __declspec Macro is used on a constructor, EA will not generate a DeclMacro tagged value for this function! (manually defining that macro after import works though)

2. When a __declspec Macro is used on a method that has a pointer or reference type as a result, the resulting code after 'generate' will not compile correctly, since the DeclMacro symbol will be generated right in front of the method name, with the '*' or '&' symbols yet before that! This does not link correctly under Visual Studio (not sure whether other compilers treat this differently). Example generated code:

Code: [Select]

void* MY_DECL foo();
Under Visual Studio, this warning will be generated:

warning C4518: '__declspec(dllexport ) ' : storage-class or type specifier(s) unexpected here; ignored

While this apparently does compile, the linkage will be wrong.