text string in generated binary file

[guylejeune]

Dear all,

when compiling the same project from different place on the computer, we get different binaries.

Digging in the .elf file, it turns out some computer paths are included:

00002511 <__func__.8045>:     2511:       4e49 5f54 5953 5f53 6e45 6261 656c 5249     INT_SYS_EnableIR     2521:       0051 682f 6d6f 2f65 656c 656a 6e75 2f65     Q./home/lejeune/     2531:       694b 656e 6974 2f73 6554 7473 685f 6861     Kinetis/Test_hah     2541:       3361 532f 4b44 702f 616c 6674 726f 2f6d     a3/SDK/platform/     2551:       6168 2f6c 6e69 2f63 7366 5f6c 6f70 7472     hal/inc/fsl_port     2561:       685f 6c61 682e 7000 6e69 3c20 3320 5532     _hal.h.pin < 32U     2571:       2f00 6f68 656d 6c2f 6a65 7565 656e 4b2f     ./home/lejeune/K     2581:       6e69 7465 7369 542f 7365 5f74 6168 6168     inetis/Test_haha     2591:       2f33 4453 2f4b 6c70 7461 6f66 6d72 732f     3/SDK/platform/s     25a1:       7379 6574 2f6d 6e69 2f63 7366 5f6c 6e69     ystem/inc/fsl_in     25b1:       6574 7272 7075 5f74 616d 616e 6567 2e72     terrupt_manager.     25c1:       0068 2030 3d3c 6920 7172 754e 626d 7265     h.0 <= irqNumber     25d1:       6900 7172 754e 626d 7265 3c20 203d 5346     .irqNumber <= FS     25e1:       5f4c 4546 5441 5255 5f45 4e49 4554 5252     L_FEATURE_INTERR     25f1:       5055 5f54 5249 5f51 414d 0058 682f 6d6f     UPT_IRQ_MAX./hom     2601:       2f65 656c 656a 6e75 2f65 694b 656e 6974     e/lejeune/Kineti     2611:       2f73 6554 7473 685f 6861 3361 532f 4b44     s/Test_haha3/SDK     2621:       702f 616c 6674 726f 2f6d 6168 2f6c 6e69     /platform/hal/in     2631:       2f63 7366 5f6c 7067 6f69 685f 6c61 682e     c/fsl_gpio_hal.h

A bit further, we even get some clear text:

00002642 <__func__.6255>:     2642:       4f50 5452 485f 4c41 535f 7465 754d 4d78     PORT_HAL_SetMuxM     2652:       646f 0065 0000                              ode...  00002658 <gpio1_InpConfig0>:     2658:       020c 0000 0001 0101 0000 0000 ffff ffff     ................         ...  00002670 <gpio1_OutConfig0>:     2670:       0100 0000 0000 0000 0001 0001 ffff ffff     ................         ...     2688:       2e2e 472f 6e65 7265 7461 6465 435f 646f     ../Generated_Cod     2698:       2f65 736f 3161 632e 6400 7669 6469 7265     e/osa1.c.divider     26a8:       2120 203d 5530 4f00                               != 0U.  000026af <__func__.8420>:     26af:       534f 5f41 6954 656d 6e49 7469 2c00 6620     OSA_TimeInit., f     26bf:       6e75 7463 6f69 3a6e 0020 7361 6573 7472     unction: .assert     26cf:       6f69 206e 2522 2273 6620 6961 656c 3a64     ion "%s" failed:     26df:       6620 6c69 2065 2522 2273 202c 696c 656e      file "%s", line     26ef:       2520 2564 2573 0a73 4300 0000 0800                %d%s%s..C...  000026fc <_global_impure_ptr>:     26fc:       0408 1fff 2d23 2b30 0020 6c68 004c 6665     ....#-0+ .hlL.ef     270c:       4567 4746 3000 3231 3433 3635 3837 4139     gEFG.0123456789A     271c:       4342 4544 0046 3130 3332 3534 3736 3938     BCDEF.0123456789     272c:       6261 6463 6665 0000                         abcdef.. 

Step to reproduce:

- new Kinetis project, with Processor Expert

- our board: TWR-K60D100M

- compiler with size optimization (-Os)

- use of the fsl_gpio component

We use a KDS 3.0 & KDSK 1.3.0 for Linux (Centos 7).

We are beginning with KDS & Eclipse, so are we missing something (particular option somewhere, ... ) ?

Removing the default debugging option (going from default -g3 to none) doesn't bring any change.

The reason I don't want to leave it the way it is:

- same source produce different output ;

- we try to do size optimization.. and this doesn't help.

Thank you for your help !

[guylejeune · Accepted solution]

Looking deeper and deeper, it seems to come from the assert function, in assert.h:

#ifdef NDEBUG /* required by ANSI standard */
# define assert(__e) ((void)0)
#else
# define assert(__e) ((__e) ? (void)0 : __assert_func (__FILE__, __LINE__, ifde\
    __ASSERT_FUNC, #__e))
# ifndef __ASSERT_FUNC
  /* Use g++'s demangled names in C++.  */
#  if defined __cplusplus && defined __GNUC__
#   define __ASSERT_FUNC __PRETTY_FUNCTION__
  /* C99 requires the use of __func__.  */
#  elif __STDC_VERSION__ >= 199901L
#   define __ASSERT_FUNC __func__
  /* Older versions of gcc don't have __func__ but can use __FUNCTION__.  */
#  elif __GNUC__ >= 2
#   define __ASSERT_FUNC __FUNCTION__
  /* failed to detect __func__ support.  */
#  else
#   define __ASSERT_FUNC ((char *) 0)
#  endif
# endif /* !__ASSERT_FUNC */
#endif /* !NDEBUG *
/
/

So passing NDEBUG as preprocessor flag seems to remove the text and paths.

The whole thing compiles and seems to run.  The code size is divided by a factor 2 or 3.

But how safe is it safe to pass this flag ?

[ErichStyger]

If you want (or need) to tweak the assert() functionality, this one might be helpful:

assert(), __FILE__, Path and other cool GNU gcc Tricks to be aware of | MCU on Eclipse

Erich

[patrickwood]

Assertions are for debugging.  You can remove them, but will not be able to get debugging assertions or messages after that.  See assert.h - Wikipedia, the free encyclopedia

[trytohelp]

Hi,

I found the following:

++++++++++++++++++++++++

2.5 assert—macro for debugging diagnostics

Synopsis

#include <assert.h>

void assert(int expression);

Description

Use this macro to embed debuggging diagnostic statements in your programs. The argument

expression should be an expression which evaluates to true (nonzero) when your program

is working as you intended.

When expression evaluates to false (zero), assert calls abort, after first printing a message

showing what failed and where:

Assertion failed: expression, file filename, line lineno, function: func

If the name of the current function is not known (for example, when using a C89 compiler

that does not understand func ), the function location is omitted.

The macro is defined to permit you to turn off all uses of assert at compile time by defining

NDEBUG as a preprocessor variable. If you do this, the assert macro expands to

(void(0))

++++++++++++++++++++++++

My example didn't used the assert function.

This is why I didn't reproduced the problem.

In addition to the NDEBUG macro you can select the linker option -s (Omit all symbol information).

By this way all debug information will be removed at elf file - if you need  -

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[guylejeune]

Hi Pascal,

thank you for your confirmation !

Can you tell me where the information from your last post can be found ?

I can't find it in the KDS doc nor the KDSK / PE help...  where should I look for it ?

BR,

Guy

[trytohelp]

Hi Guy,

Good question ... I don't remember what I did 2 days ago ... :smileycry:

Yes ...

Please have a look to the folder:

    \KDS_3.0.0\toolchain\share\doc\gcc-arm-none-eabi\pdf

The libc.pdf manual contains the info page 8.

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[guylejeune]

Great, thanks !

I was not aware of this pdf folder !

[trytohelp]

Hi

The project generates the .elf file.

The .elf includes the code and debug information.

By debug information I mean all information that the debugger needs to debug the application.

This is including the path of all source files in order to display the file associated to the executed code.

If the same project is moved to another folder, the elf file will change too.

Now you can generate a Srecord file (bin, hex, ...) containing code only without debug info.

To enable the Hex/Bin Converter you need to enable the "Create flash image"  option under C/C++ build - Settings - Toolchains tab.

now back to Tool Settings tab, a new config is available:

    Cross ARM GNU create Flash Image

Is it the option/process you're looking for ?

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[guylejeune]

Hi Pascal,

the suggested action is not solving the problem (see my post from Nov 27).

Is it possible to remove the "assumed answered tag" ?

It looks it is the same problem as https://community.freescale.com/thread/380496 .

[trytohelp]

Hi,

What is the Editor used to open the bin and elf file ?

By default inside KDS it's not possible to open these files.

I've UltraEdit and I can open the elf and bin files.

Did you tried to set the option -j .text and -j .data ?

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[guylejeune]

Hi Pascal,

I'm opening the elf file with the objdump command: objdump -d file.elf | less

Using the suggested options (-j .text and -j .data) to the flash image creator (objcopy) effectively removes all paths and ascii text from the binary.

But this can not be a functional binary file:

- the vector table is removed as well ;

- the paths and ascii text are used by the rest of the code.

So this is not the solution we are looking for.

These paths & ascii text should not be part of the .elf file (they are not debug information but real code part).

[guylejeune]

Hi Pascal,

thank you for looking into this.

The extract of the elf file I've printed above are included in the binary file.

For example, if I see the following line in the .elf

2511:      4e49 5f54 5953 5f53 6e45 6261 656c 5249    INT_SYS_EnableIR  

I find the corresponding data in the generated binary:

0002510 495b 544e 535f 5359 455f 616e 6c62 4965

So I still end-up with paths and other "printf-like" text in ascii in my binary files.

Do you have any idea on how to remove them ?

GL