Debug information missing when -gc-section option is used

Bug #1912196 reported by Darius Galis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Arm Embedded Toolchain
New
Undecided
Unassigned

Bug Description

Hello,

Giving the files t1.c ,t2.c, t2.h which contain secure entry functions.

$cat t1.c
#include "t2.h"
int __attribute__((cmse_nonsecure_entry)) secure_func1(int x)
{
  return func1(x);
}
int __attribute__((cmse_nonsecure_entry)) secure_func2(int x)
{
 return func2(x);
}
int main()
{
  return 0;
}

$cat t2.c
#include "t2.h"
int func1(int x)
{
 return x + 3;
}
int func2(int x)
{
 return x - 2;
}

$cat t2.h
#ifndef SECURE_FUNC_H_
#define SECURE_FUNC_H_
extern int func1(int x);
extern int func2(int x);
#endif /* SECURE_FUNC_H_ */

1. Compiling them with the following options:

-mcpu=cortex-m33 -mthumb -mfloat-abi=hard -mfpu=fpv5-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -mcmse -g -c t2.c t1.c -Wunused -Wuninitialized -Wall -Wextra -Wmissing-declarations -Wconversion -Wpointer-arith -Wshadow -Wlogical-op -Waggregate-return -Wfloat-equal -g -std=c99 -mcmse

2. Then linking them with arm-none-eabi-gcc -mcpu=cortex-m33 -mthumb -mfloat-abi=hard -mfpu=fpv5-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -mcmse -g -Wl,-section-start=.gnu.sgstubs=0x190000 -Wl,-gc-sections --specs=rdimon.specs t1.o t2.o -o test.out

3. arm-none-eabi-objdump --dwarf=info test.out > test.txt
Search for func1 or func2 . There is no debug information for func1 and func2

But, if instead of the files t1.c and t2.c you are using the file t3.c (which contains the same functions but they are written in just one file), by repeating steps 1 to 3, the debug information for func1 and func2 is now present in the objdump dump file.

$cat t3.c
int func1(int x)
{
 return x + 3;
}
int func2(int x)
{
 return x - 2;
}
int __attribute__((cmse_nonsecure_entry)) secure_func1(int x)
{
  return func1(x);
}
int __attribute__((cmse_nonsecure_entry)) secure_func2(int x)
{
 return func2(x);
}
int main()
{
  return 0;
}

I found the following patch from here: http://sourceware-org.1504.n7.nabble.com/PATCH-BINUTILS-ARM-Mark-debug-sections-of-file-containing-cmse-entry-functions-td579555.html . But given the current testcase, it seems that the patch is not complete.

Could you please let me know if it's a known issue or if you have any plans for fixing it?

Best Regards,
Darius Galis

Revision history for this message
SRINATH PARVATHANENI (sripar01) wrote :

Hi Darius,

Thanks for posting this.

I have tested the mentioned issue with latest GCC for t1.c and t2.c separate files and could not reproduce the issue and debug information for the functions func1 and func2 is available in the generated executable.

$ arm-none-eabi-gcc -mcpu=cortex-m33 -mthumb -mfloat-abi=hard -mfpu=fpv5-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -mcmse -g -c t2.c t1.c -Wunused -Wuninitialized -Wall -Wextra -Wmissing-declarations -Wconversion -Wpointer-arith -Wshadow -Wlogical-op -Waggregate-return -Wfloat-equal -g -std=c99 -mcmse
t1.c:2:43: warning: no previous declaration for 'secure_func1' [-Wmissing-declarations]
    2 | int __attribute__((cmse_nonsecure_entry)) secure_func1(int x)
      | ^~~~~~~~~~~~
t1.c:6:43: warning: no previous declaration for 'secure_func2' [-Wmissing-declarations]
    6 | int __attribute__((cmse_nonsecure_entry)) secure_func2(int x)
      | ^~~~~~~~~~~~

$ arm-none-eabi-gcc -mcpu=cortex-m33 -mthumb -mfloat-abi=hard -mfpu=fpv5-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -mcmse -g -Wl,-section-start=.gnu.sgstubs=0x190000 -Wl,-gc-sections --specs=rdimon.specs t1.o t2.o -o test.out

$ arm-none-eabi-objdump --dwarf=info test.out | grep "func1" -w
    <67> DW_AT_name : (indirect string, offset: 0x15a): func1

$ arm-none-eabi-objdump --dwarf=info test.out | grep "func2" -w
    <4a> DW_AT_name : (indirect string, offset: 0x148): func2

$ arm-none-eabi-gcc -v
Using built-in specs.
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210107 (experimental)

$ arm-none-eabi-ld -v
GNU ld 2.35.50.20210107

Could you please include with which Embedded Toolchain you observed above issue. That might have been build with old binuilts.

Regards,
Srinath.

Revision history for this message
Darius Galis (dariusg94) wrote :

Hello,

Thank you for replying!

I've used the latest 10-2020-q4-major GCC ARM Embedded version:

$arm-none-eabi-gcc -v
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20201103 (release) (GNU Arm Embedded Toolchain 10-2020-q4-major)

$arm-none-eabi-ld -v
GNU ld (GNU Arm Embedded Toolchain 10-2020-q4-major) 2.35.1.20201028

Could you please let me know from where I could download the toolchain that you've used? Since the versions are updated, and the bug cannot be reproducible, there might be a fix in the upcoming toolchain.

Best regards,
Darius Galis

Revision history for this message
Darius Galis (dariusg94) wrote :

Hello,

Could you please let me know if you have any updates related to this issue?

Best Regards.
Darius Galis

Revision history for this message
SRINATH PARVATHANENI (sripar01) wrote :

Hi Darius,

GNU Arm Embedded Toolchain 10-2020-q4-major was generated with a specific SHA in binutils dated 28th Oct, 2020 and the above issue was fixed in binutils master.

There isn't any Arm toolchain available with this fix to download yet.

We shall include this fix in our next Embedded toolchain planned to release in Q2 CY'21.

Regards,
Srinath.

Revision history for this message
Alex Coplan (alecop) wrote :

Hi Darius,

The issue should be fixed with GCC 11. Arm will have a new release of the embedded toolchain based on GCC 11 available soon, likely by the end of January.

Kind regards,
Alex

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.