Re: cXprop/CComp: reporting 2 bugs
Nathan Cooprider
I looked into the two bugs you mentioned today. Unfortunately, the first
problem occurs inside CIL's parser and not in cXprop. The current
version of CIL still does not deal with labels for operands in inline
assembly, and adding that feature to their parser is beyond what I have
time to do. If you were to get it updated in CIL, I could then update
cXprop to use the patched CIL (or patch cXprop's version of CIL).
I have not come across the problem you describe with CComp. The version
included with the latest cXprop distribution should be the most current.
However, there may be some code rot in the CComp code because it has not
been actively used (as far as I know) in over a year. I can look into it
some more if you send me some code that trips the bug and the command
you are running.
Sorry I cannot be more helpful!
Nathan
Aurélien Francillon wrote:
> Hi,
> I have two problems with cXprop/CComp I downloaded on
> your web page. I have workarounds for them but you may be
> interested to know about them and/or fix them (which would actually
> be great ;)
>
> The first problem is with the parsing of inline assembly when using
> labels for the operands (as described in avr-libc manual page: Inline
> Assembler Cookbook ) the source code parsing fails with the message:
>
> test_asm.c[16:0-0] : syntax error
> Parsing error
> Fatal error: exception Frontc.ParseError("Parse error")
>
> In "real world" the problem occurs with the cXprop tool and
> avr-libc-1.6.2
> when using eeprom related functions:
>
> /usr/lib/gcc/avr/3.4.6/../../../../avr/include/avr/eeprom.h[259:0-0] :
> syntax error
> Parsing error
> Fatal error: exception Frontc.ParseError("Parse error")
>
> The problem (inline assembly with labels ) is in function
> eeprom_write_byte
> in avr-libc 1.6.x (labels for asm operands wasn't used with in version
> 1.4 ).
> Note that the code compiles fine (and works) under gcc.
>
> I attach a small test case with one simple example with inline
> assembly test_asm.c, when I uncomment the line "//#define BUG"
> compilation fails.
>
> The second test case is using the eeprom.h from avr-libc. I included the
> two version of eeprom.h that I tested in the avr directory when
> eeprom.h links to the 1.4 version everything works well, when I link to
> the version 1.6.x the compilation fails.
>
> I have another problem, with CComp this time, I used CComp from the same
> tar.gz it doesn't seems to be separate packages right ?
> I'm not sure that CCcomp is responsible of it, it's related to definition
> of uint*_t types :
> ./myfile.cil.c:40: error: conflicting types for 'uint16_t'
> /usr/lib/gcc/avr/3.4.6/../../../../avr/include/stdint.h:124: error:
> previous declaration of 'uint16_t' was here
> ./myfile.cil.c:41: error: conflicting types for 'uint32_t'
> /usr/lib/gcc/avr/3.4.6/../../../../avr/include/stdint.h:126: error:
> previous declaration of 'uint32_t' was here
> ./bootloader.cil.c: In function `main':
>
> Actually the problem is that the generated xxx.cil.c file includes
> cxp_compression_avr.h which itself includes avr/pgmspace.h
> which includes inttypes.h.
> Both inttypes.h and the cil.c files declare uin32_t and uint16_t tyes ...
> Maybe this bug is triggered only when using avr-libc 1.6 I actually
> haven't tried earlier versions.
> An easy workaround would be to enclose the typedefs in the generated
> cil.c file
> with in a "#ifdef __INTTYPES_H_ /#endif" block.
>
> I don't have test cases that triggers this bug, I can try to provide
> one if
> you need it. If you need any other information (program versions etc..)
> don't hesitate to ask me.
>
> And BTW the tools are great ! Thanks for providing them!
>
> Best regards,
> Aurélien
>
>