|
Post by Martin Nielsen on Aug 25, 2015 15:44:02 GMT -5
Oops - I just noticed your question - sorry for not responding sooner. I'll have a look at the problem and be back within the next couple of days. In the meantime please have a look at the solution to segmentation fault in latest testape release in cygwinFrom the error message "bad reloc ..." it looks like it is a cygwin-mingw issue and if so, it is caused by the cygwin toolchain rather than the coverage option. Br, Martin
|
|
|
Post by Martin Nielsen on Nov 11, 2014 15:02:17 GMT -5
Hi Joakim
The testape library supplied in release 1171 for windows are compiled with a gcc having the following signature
Target: i686-w64-mingw32 Configured with: --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32
So you need a compatible gcc compiler installed in cygwin. I have used the packages mingw64-i686-binutils and mingw64-i686-gcc in a fresh cygwin installation and they produce object files that are compatible with testape.a
Unfortunately there is one more twist: TestApe do not recognize i686-w64-mingw32-gcc.exe, so you also need to add a symbolic link for gcc and point it to i686-w64-mingw32-gcc.exe, e.g
$ ln /usr/bin/i686-w64-mingw32-gcc.exe /usr/bin/gcc.exe
Finally you you need to provide the -mgw option when you compile to trigger the usage of the build in windows standard library msvcrt.lib.
With that in mind, sample26 can be compiled like this
$ testape -mgw gcc sample26.c converter.c testape.a
Next beta wil contain a fix for the problem about not being able to recognize i686-w64-mingw32-gcc.exe
Br, Martin
|
|
|
Post by Martin Nielsen on Nov 11, 2014 14:50:14 GMT -5
Hi Joakim Thank you for reporting this error. Cygwin/gcc has not been part of the platforms that is being tested before a release – the assumption being ( and the has been true for several releases) that mingw would work just fine with cygwin/gcc also. Apparently this is not the case anymore, with the version of mingw-w64 that I used to build the windows releases. The problem is easy for me to reproduce – e.g. when I run sample1, I noticed that defaults mocks are created for a couple of windows library functions – one of them being __ms_vsnprintf. I think that this means that gcc is not linking with the build-in library on windows, but instead with the cygwin equivalents.
There used to be a option to cygwin/gcc to use windows libraries (the -mno-cygwin option), but this is no longer to be found in the GCC that I installed for cygwin yesterday, but if you have it in your gcc, you could try that.
Alternatively you can use mingw-w64 for the tests, but I realize that this is a big step.
Anyway, I will work on a solution, and let you know, once I have it figured out.
|
|
|
Post by Martin Nielsen on Aug 24, 2014 2:31:05 GMT -5
TestApe Release 1171 available, Aug 20th 2014
It has been a long time since last official release and the list of bugfixes, features and supported platforms accumulating in the beta has grown substantially. I am happy to annouce that a new release is ready.
The TestApe unit test system is a Linux/Windows based unit test system for embedded sw written in C. It contains a full featured mocking system that is easy to understand and use. TestApe is designed to be part of the build process. With a quick turn around time when writing new tests ( no need to write tons of dummy stubs with long switch cases ), it is also well suited for a SCRUM based development process.
Installation packages are available for GCC/Linux on Intel and ARM platforms, GCC/CygWin/MinGw as well as Visual Studio 2010/Windows 7, Vista or XP
Highlights One of the major updates in this release are the support for the ARM processor. The processor dependent code of the mocking system has been isolated and a version of it for the ARM processor has been implemented. This release contains documentation and sample code that demonstrates how to customize TestApe, so that it can run on bare metal configurations or other operating systems.
If you already have used one of the earlier version, you will see a difference in the output from the tests. The detailed log output is now disabled by default. Only short error messages, with file and line references, are shown for those tests that fail.
Exception handling has been overhauled and it is now possible to write tests that can intercept exceptions and check that they happen at the right time.
There are new macros and syntax changes to existing ones. Existing macros that are deprecated will still work as they used to. The new macros validates masked bit, byte and word values and they make it possible to use the mocking system with other test tools.
The Linux packages are tested on i386 Ubuntu 14.04 and on armhf Raspbian/Wheezy. The windows packages are tested in Windows 7 and Windows Vista with GCC/MinGW-w64, Visual Studio Express 2010 and Visual Studio Enterprise 2010.
More detailed information, documentation and release note can be found on download page here testape.com/testape_download.php
|
|
|
Post by Martin Nielsen on Dec 22, 2013 17:29:29 GMT -5
Hi Benjamin
I may have identified a workaround
if you modify the mytestfunction_testape.c like this -->
extern int testape_error_handler; extern int testape_validate_fp_accuracy; extern int testape_build_info;
void test_testfunktion4(void) { int dummy = testape_error_handler+ testape_validate_fp_accuracy+testape_build_info; EXPECT(add); EXPECT(mult); VALIDATE(myown_main(),0); }
Then your sample will run
The problem is related to testape.a not beeing a complete archieve and perhaps the order of the object files inside testape.a
Br, Martin
|
|
|
Post by Martin Nielsen on Dec 10, 2013 16:28:09 GMT -5
Hi
Thank you for the files.
testape.c which is generated by the instrumenter is incomplete. It do not contain stubs for all the unresolved externals.
This is the output
c:\TEMP\ccd7BDhO.o:mytestfunction_testape.c:(.text+0x7): undefined reference to `add$$tah' c:\TEMP\ccd7BDhO.o:mytestfunction_testape.c:(.text+0x44): undefined reference to `mult$$tah' c:\TEMP\ccd7BDhO.o: bad reloc address 0x20 in section `.eh_frame'
It should have looked like this
c:\TEMP\ccd7BDhO.o:mytestfunction_testape.c:(.text+0x7): undefined reference to `add$$tah' c:\TEMP\ccd7BDhO.o:mytestfunction_testape.c:(.text+0x44): undefined reference to `mult$$tah' c:\TEMP\ccd7BDhO.o:mytestfunction_testape.c:(.text+0x7): undefined reference to `testape_build_info' c:\TEMP\ccd7BDhO.o:mytestfunction_testape.c:(.text+0x44): undefined reference to `testape_error_handler' c:\TEMP\ccd7BDhO.o:mytestfunction_testape.c:(.text+0x7): undefined reference to `testape_validate_fp_accuracy'
I notice this is your output -->
c:\TEMP\ccd7BDhO.o: bad reloc address 0x20 in section `.eh_frame'
Which I think causes the linker to abort the linkage prematurely (before processing the testape.a). After having updated my version of mingw to the most recent version, I too have exactly the same problem locally with the files you send me. So, you're not doing anything wrong :-)
It might be a bit premature conclusion and without understanding the problem completely, I can't help feel that this is caused by an error in lastest mgw distribution.
I will continue to investigate, but currently I have not identifed a workaround that you can use.
Br, Martin
|
|
|
Post by Martin Nielsen on Dec 9, 2013 12:33:42 GMT -5
Hi Benjamin
Thanks for your feedback. I can see that you have used the -o option. It will save some files, that will help me analyze the problem.
Could you mail me these files please (martin [at] testape.com )
testape.c testape.err testape.log testape_prelink_args testape_prelink_result
Br, Martin
|
|
|
Post by Martin Nielsen on Dec 8, 2013 16:36:31 GMT -5
Hi André Thank you very much for the nice QT howto and for the feature requests. I will add all of those good ideas before next release. Br, Martin
|
|
|
Post by Martin Nielsen on Oct 20, 2013 12:53:02 GMT -5
Question: Can I get a version of TestApe for the ARM platfom ? Aswer: Yes - ARM platforms are supported.
|
|
|
Post by Martin Nielsen on Oct 20, 2013 11:58:30 GMT -5
The next version of TestApe ( beta coming within a couple of weeks ) will include support for the ARM processor family. That includes all aspects of testape, testing, mocking and floating point support.
It will be based on libc with the gnueabi calling convention, but adaptations will be possible for bare metal and other configurations.
|
|
|
Post by Martin Nielsen on Oct 20, 2013 11:50:06 GMT -5
Hi André
I would say: include SCI code for your new test and keep the function calls to SCI code unmocked (for the majority of the new tests) - Keep the mocks you have already written when you tested the SCI code and use these in the test for the new module. If you need to test special error handling in your new code, based on exit codes from SCI code, then you can choose to mock SCI function calls, however chances are, that you already have a test for the SCI module that you can combine with the new tests for these situations.
I am aware, that I am against one of the mantras within test driven development ( that you should keep your module under tests as small as possible, preferably test on funciton level). It is however my practical experience that doing this, will lead you to tons of tests, but these tests will be without value, if you later need to refactor the code. In fact they will be counterproductive, since you will have to refactor both the test and the code that it is testing.
Therefore I always test at the area of my (our team) resposibillity - e.g. include all those modules that I/(we) am responsible for, and mock the interface for which I/(we) rely on code from others.
This gives me the oppertunity to use the test, if I later want to refactor my code - the tests will then help me and not work against the refactor.
Br, Martin
|
|
|
Post by Martin Nielsen on Sept 5, 2013 15:48:05 GMT -5
Hi André Thanks for the files - looking at them, it was pretty obvious that I did not make a proper test for this (shame on me ) I now have a full test for german output in my regression test suite for testape. Now it MUST work :-) new beta is on the site Br, Martin
|
|
|
Post by Martin Nielsen on Sept 4, 2013 14:21:33 GMT -5
Hi André
Sorry for all the trouble - hope you have the energy to try one more time. Could you modify the makefile ( add the -o option ) like it is shown below
sample2: sample2.c calc.c add.c testape -o cl /Zi sample2.c calc.c add.c testape.lib sample2
and then run
nmake clean sample2
The instrumenter will skip the cleanup part and leave some temporary files. The interesting files are
testape.c testape.err testape.log testape_prelink_args testape_prelink_result
If you could zip and send them to martin[at]testape.com, then perhaps I can understand what is going on
Br, Martin
|
|
|
Post by Martin Nielsen on Sept 3, 2013 13:29:07 GMT -5
Hi
This time it is something else :-)
In the first output command line was
cl /Zi sample1.c calc.c add.c testape.obj testape.lib in the second output commandline was
cl /Zi sample2.c calc.c add.c testape.lib /link /entry:main
testape.obj is missing
testape.obj contains exactly the function that it is complaining about later. So, for one reason or the other, it could not generate testape.c and testape.obj. The default behaviour is the to fall through to pass through linking. Admittet, a proper error message might have made this easier to spot :-)
Could these and other temporary files be locked ? Do the user have access to create/remove these files in this directory ?
Try and run nmake clean or remove them manually.
Br, Martin
|
|
|
Post by Martin Nielsen on Sept 1, 2013 16:35:56 GMT -5
Hi André
A have made a new beta release, containing a correction that should allow TestApe to handle the German localization of the MS Compiler.
Thanks for the hints about this complicated issue and the proposals on how to improve the batch files.
Br, Martin
|
|