I have found that some bits of code when encountered by abc2xml will make the tool to give up parsing (close the xml file at that point) and go to the next file. Here are some examples:
this fails: return ( *( (volatile uint32_t *)(add) ) );
this works: return ( *(uint32_t *)(add) );
2) Preprocessor "defined"
#if (defined R_SYMBOL)
The same happens with "#if (!defined R_SYMBOL)" or with more complex "#if (defined R_SYMBOL_1) || (defined R_SYMBOL_2)"
3) comment is present at the end of the following code (deleting the comment put by uncrustify will fix the problem):
#endif /* ifdef PATCH_TO_SIMULATE_ERRORS */
By the debug output (set to 2) it seems to be that the tool enters in some loop and then it exits maybe due to some internal error .... It is just a guess because I see lots and lots of the same pattern.
Other smaller problems I spotted, that may be related to other tools:
4) Line "data &= 0x0000FFFFuL;" in NSD appears as "data 0x0000FFFFuL"
5) Underscores in function names disappear from function names in NSD: e.g.: function "R_FDL_UFct_FlashOpStart" is shown as "R FDL UFct FlashOpStart"
PS: Problematic as it may be, but the tool is still impressive.
Hello Mr. Robas.
I check it out at the week end. If you have an compileable example-file that demonstrate your problems, please attache it to this topic.
This post was deleted and later re-added:
Attached are files for two cases: passing and failing in case of volatile. Other cases can be tested by uncommenting the proper code.
I have added some defines TEST_TAG_xx and in the fail case it can be seen that this defines do not appear (in xml or nsd output) after the affected code.
There is another abort case at "#define STR(x)".
Hope that helps,
Please find attached a first debuged version of the LangPack subfolder ansi_c
I have changed the 3 grammar-files "ANSI_C_PreProcedure.a2x", "ANSI_C_Expression.a2x" and "ANSI_C_Source_C_only_grm.a2x" as well as the diagram-description "nsd_ansi_c_cfg.x2a".
Please test if it solves your first 4 points (crash of abc2xml and missing &= in diagram) without some other trouble.
If you find some other problems or if you have still some doubts please don't hesitate to argue. If the mentioned points are solved, please post this also.
Point 5 (missing underscores in function-name) takes a little bit longer. To be honest I configured the replacement of the underscore by a space as wanted feature. Now I have to rethink this again to offer a solution for both both posibilities. Please give me some time.
Thanks for your fast response.
I will try the updated LangPack and come back tomorrow with the results.
I tested the previous cases and all passed except:
- "#define STRINGIZE(str) #str" that aborted. However, it is not a problem because it is not part of the code I have to document.
- "#if (defined R_SYMBOL)" will loose the macro definition in NSD. It will be shown as "#if ()" no matter if the macro is defined or not. Problem is visible in nsd\r_fdl_hw_access_c.html file in the attached files.
Here is the next trial to solve the problems you mentioned in your mail above.
You will see that some more files are changed now. On the one side I had to add some grammar-rules in the a2x-files and some more diagram descriptions in the x2a-files. Furthermore I added a littel bit in the xml-configuration since the new grammar-rules for the preprocessor stringize and pasting defines are non-phrased rules (spaces inside are not ignored).
How ever pleas test it and don't hesitate to argue if you have some more doubts.
PS.: Due to some problemes in my sourceforge-project I was not able to dowload your last 7z-file before this post of the debug-result. Thus pleas accept my appologize that I used it not to test my solution I offer you now.
Your newest files fixed the issues with "#str" and passed all the previous tests. But then there is a new one: conditional compilation of one function. For example:
#if R_FDL_COMPILER == R_FDL_COMP_GHS
void foo (void)
will be skipped. That is because in xml this whole part is seen as a single piece of code.
I am yet to determine more precisely what happens because I have seen NSD's both skip and abort when this code is encountered. I will come back with details.
Its good to read that the parser definitions are working for you. But the issue mentioned in your last post is a new thing and should be handled in a new topic. Furthermore it seems to be a bug in the binary. Thus I have created a ticket in the forum "Bugs & Requests" with the ID 7 and the title "compiler switch not parsed correctly". Please take a look here to find more information.
Furthermore don't misunderstand me if I ask you to open for every new issue a new topic. Your comments are very important for this project not only for me, since it helps me to improve the tools but also for other users, if they are able find some necessary information in our discussion. But if we change to an other point without creating a new topic this will not be seen by other users.
Thus please continue posting doubts and issues. But please open for every point a ne topic and if you think you found a bug please feel free to create a ticket in the forum "Bugs & Requests".
With mamy thanks for your help,
I agree this that it is better to keep things organized but for whatever reason I can not see any reply link/button/input box on the "Bugs and Requests" ticket page. Could it be that some admin settings are not right ?
For the moment I will reply here about the last issue. I do not think the value of the macros are the problem because even the following code will be seen as a one long directive in xml output.
void foo (void)
On a longer piece of code, I have seen that all functions following such code appear as "directives" in xml, and are missing from NSD.
PS: It might have been more useful that I have created some tests from such small pieces of code. I was thinking on some python script since I am not that knowledgeable in cpp & xml. What do you think ?
First let's see how to give you access to the ticket. As you mentioned I didn't configured the user-rights correctly. But I hope it works now if you are logged in at sourceforge.
Second your Idea to create some small tests for this sounds very usefull as well as your idea to automize their use for example with python. On the otherside the tools to test them self expect their data written in the programming language that should be parsed and as xml-configuration. For me it would be helpfull to have some examples I'm allowed to add to my example code in the distribution. Thus please think about what from your code is free to use and what not.
Third your current problem. In the meanwhile I analysed it and I will add my results to the associated topic under "Bugs & Requests". I hope this helps you.