0

I am compiling a simple c file with gcc on Linux and using readelf to find info of symbols. The function names (and perhaps other symbols - I didnt check) are trimmed to 25 characters.

Is there a way to tell compiler/linker to keep longer symbols ?

Versions:

  1. Compiler : gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
<prompt>$ cat test_long_fnames_in_elf.c 
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>

void verly_long_function_xjsakdghajkshdlasjkldashjkldhasjklfdsjkhfsdjkhfsdjklhdsjkl_v1(uint32_t val)
{
        int i = 0;
    for (i = 0 ; i < val; i++)
    {
        printf("%d\n", i);
    }
}

void verly_long_function_xjsakdghajkshdlasjkldashjkldhasjklfdsjkhfsdjkhfsdjklhdsjkl_v2(uint32_t val)
{

        int i = 0;  
        for (i = 0 ; i < val; i++)
    {
        printf("This is i = %d\n", i);
    }
}

int main()
{
    verly_long_function_xjsakdghajkshdlasjkldashjkldhasjklfdsjkhfsdjkhfsdjklhdsjkl_v1(5);
    verly_long_function_xjsakdghajkshdlasjkldashjkldhasjklfdsjkhfsdjkhfsdjklhdsjkl_v2(5);
}

<prompt>$ gcc test_long_fnames_in_elf.c -g -o test_long_fnames_in_elf.elf                                                                                                                                        <prompt>$ readelf -a te.elf | grep long

<prompt>$ readelf -a test_long_fnames_in_elf.elf | grep long
    41: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS test_long_fnames_in_elf.c
    52: 000000000040052d    61 FUNC    GLOBAL DEFAULT   13 verly_long_function_xjsak            <--  Function symbol is trimmed
    62: 000000000040056a    61 FUNC    GLOBAL DEFAULT   13 verly_long_function_xjsak            <--  Function symbol is trimmed

<prompt>$ 

  • What does the debugger show? Did you consider that only the output in the shell could be truncated? – the busybee Nov 02 '22 at 15:20
  • The C standard already requires to allow for a minimum of 31 significant initial characters in external identifiers (and 64 for internal identifiert). If the identifiers were chopped by compiler and linker you would probably get an error for duplicate identifiers. What you see is either a limitation of debug information or of the `readelf` tool. See "5.2.4.1 Translation Limits" of C standard – Gerhardh Nov 02 '22 at 15:25
  • If `readelf` has an issue [of which I'm skeptical], then try `objdump`. Or, try `nm` or even `strings -`. Or, just write your own program that does `mmap` and scans for the strings. You could also try `as` and create the `.o` to test limits (if any) of the compiler itself. – Craig Estey Nov 02 '22 at 16:10

2 Answers2

0

Is there a way to tell compiler/linker to keep longer symbols ?

The compiler is keeping longer symbols, but readelf doesn't display them.

Here is the output on my system, using readelf from binutils-2.39:

readelf -a a.out | grep long
    18: 0000000000001139    68 FUNC    GLOBAL DEFAULT   15 verly_long_funct[...]
    29: 000000000000117d    68 FUNC    GLOBAL DEFAULT   15 verly_long_funct[...]

Compare to:

readelf -Ws a.out | grep long
    18: 0000000000001139    68 FUNC    GLOBAL DEFAULT   15 verly_long_function_xjsakdghajkshdlasjkldashjkldhasjklfdsjkhfsdjkhfsdjklhdsjkl_v1
    29: 000000000000117d    68 FUNC    GLOBAL DEFAULT   15 verly_long_function_xjsakdghajkshdlasjkldashjkldhasjklfdsjkhfsdjkhfsdjklhdsjkl_v2
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
-1

Works with objdump. Thanks Craig Estey

    <prompt>$ objdump -t test_long_fnames_in_elf.elf | grep long
    test_long_fnames_in_elf.elf:     file format elf64-x86-64
    0000000000000000 l    df *ABS*  0000000000000000              test_long_fnames_in_elf.c
    000000000040052d g     F .text  000000000000003d              verly_long_function_xjsakdghajkshdlasjkldashjkldhasjklfdsjkhfsdjkhfsdjklhdsjkl_v1
    000000000040056a g     F .text  000000000000003d              verly_long_function_xjsakdghajkshdlasjkldashjkldhasjklfdsjkhfsdjkhfsdjklhdsjkl_v2
    <prompt>$ 
  • Downvoting because: 1. it's not an actual answer and 2. you should _never_ use `objdump` on ELF systems because https://stackoverflow.com/a/22188584/50617 – Employed Russian Nov 04 '22 at 00:53