USER_LABEL_PREFIX appear on internal assembler labels

USER_LABEL_PREFIX appear on internal assembler labels

[Benjamin Burtscher]

Hello,
 
I have a problem with internal assembler labels. We use #define USER_LABEL_PREFIX "_" in our i386 config to prefix global symbols.
This is working, but the problem is that local internal assembler labels like ".L1" also get the prefix ("_.L1"), but not all of them. This produces unresolved symbols at the target.
The -fleading-underscore switch produces the same problem.
 
We can’t update to a newer version of GCC at the moment, because we use a third-party target platform.
 
It would be great If you can tell me the interesting code lines where the problem could be so that I can fix it.
I have attached 2 backtraces. In the first, the problem appears at a internal label. The second backtrace is the case where it works correctly with a global function.
 
 
Thanks in advance and Best regards,
Benjamin Burtscher
 
 
Compiled with MinGW with the following configuration:
 
#The relative pathnames must not be changed!
../../../src/gcc-4.1.2/configure \
    --prefix=$MSYS/local/bachmann \
   --host=i686-pc-mingw32 \
    --target=i386-wrs-vxworks \
    --with-languages=c,c++ \
    --enable-languages=c,c++ \
    --enable-sjlj-exceptions \
    --disable-nls \
    --without-libiconv-prefix \
    --with-headers=../../../src/vxworks-headers \
    --with-pkgversion="$DATE"
 
 
 
(gdb) bt
#0  assemble_name_raw (file=0x75182960 <msvcrt!_iob+96>, name=0x28f990 ".L19")
    at ../../../../src/gcc-4.1.2/gcc/varasm.c:2034
#1  0x0057148f in output_asm_label (x=<optimized out>) at ../../../../src/gcc-4.1.2/gcc/final.c:3184
#2  0x00571d58 in output_asm_insn (operands=0x9395a0 <recog_data>,
    template=0x8042e9 <eliminables.16431+9801> "%+j%C1  %l0") at ../../../../src/gcc-4.1.2/gcc/final.c:3092
#3  output_asm_insn (template=0x8042e9 <eliminables.16431+9801> "%+j%C1 %l0", operands=0x9395a0 <recog_data>)
    at ../../../../src/gcc-4.1.2/gcc/final.c:2958
#4  0x005728c0 in final_scan_insn (insn=0x20e1850, file=0x75182960 <msvcrt!_iob+96>, optimize=0, nopeepholes=0,
    seen=0x28fc0c) at ../../../../src/gcc-4.1.2/gcc/final.c:2499
#5  0x00572ec4 in final (first=0x20de520, file=0x75182960 <msvcrt!_iob+96>, optimize=0)
    at ../../../../src/gcc-4.1.2/gcc/final.c:1617
#6  0x00572f87 in rest_of_handle_final () at ../../../../src/gcc-4.1.2/gcc/final.c:3949
#7  0x00526344 in execute_one_pass (pass=0x7a7160 <pass_final>) at ../../../../src/gcc-4.1.2/gcc/passes.c:827
#8  0x00527023 in execute_pass_list (pass=0x7a7160 <pass_final>) at ../../../../src/gcc-4.1.2/gcc/passes.c:859
#9  0x00527036 in execute_pass_list (pass=0x7a5ce0 <pass_postreload>) at ../../../../src/gcc-4.1.2/gcc/passes.c:860
#10 0x00527036 in execute_pass_list (pass=0x7a5d20 <pass_rest_of_compilation>)
    at ../../../../src/gcc-4.1.2/gcc/passes.c:860
#11 0x0052ef92 in tree_rest_of_compilation (fndecl=0x20b5b80) at ../../../../src/gcc-4.1.2/gcc/tree-optimize.c:419
#12 0x0040ce7c in c_expand_body (fndecl=0x20b5b80) at ../../../../src/gcc-4.1.2/gcc/c-decl.c:6689
#13 0x004a3962 in cgraph_expand_function (node=0x20b5c00) at ../../../../src/gcc-4.1.2/gcc/cgraphunit.c:1141
#14 0x004a3a4d in cgraph_assemble_pending_functions () at ../../../../src/gcc-4.1.2/gcc/cgraphunit.c:358
#15 cgraph_assemble_pending_functions () at ../../../../src/gcc-4.1.2/gcc/cgraphunit.c:341
#16 0x004a4169 in cgraph_finalize_function (decl=0x20b5b80, nested=0 '\000')
    at ../../../../src/gcc-4.1.2/gcc/cgraphunit.c:461
#17 0x0040d1dd in finish_function () at ../../../../src/gcc-4.1.2/gcc/c-decl.c:6658
#18 0x0044356e in c_parser_declaration_or_fndef (parser=0x1c4e168, fndef_ok=1 '\001', empty_ok=<optimized out>,
    nested=0 '\000', start_attr_ok=1 '\001') at ../../../../src/gcc-4.1.2/gcc/c-parser.c:1307
#19 0x00444d73 in c_parser_external_declaration (parser=0x1c4e168) at ../../../../src/gcc-4.1.2/gcc/c-parser.c:1071
#20 0x0044586c in c_parser_translation_unit (parser=0x1c4e168) at ../../../../src/gcc-4.1.2/gcc/c-parser.c:977
#21 c_parse_file () at ../../../../src/gcc-4.1.2/gcc/c-parser.c:6260
#22 0x00436904 in c_common_parse_file (set_yydebug=0) at ../../../../src/gcc-4.1.2/gcc/c-opts.c:1152
#23 0x00500adc in compile_file () at ../../../../src/gcc-4.1.2/gcc/toplev.c:991
#24 do_compile () at ../../../../src/gcc-4.1.2/gcc/toplev.c:1952
#25 toplev_main (argc=16, argv=0x1c21140) at ../../../../src/gcc-4.1.2/gcc/toplev.c:1984
#26 0x007a0758 in main (argc=16, argv=0x1c21140) at ../../../../src/gcc-4.1.2/gcc/main.c:35
(gdb)
 
 
 
 
(gdb) bt
#0  assemble_name_raw (file=0x75182960 <msvcrt!_iob+96>, name=0x20a0b39 "CNew_RpcDeinit")
    at ../../../../src/gcc-4.1.2/gcc/varasm.c:2034
#1  0x00571666 in output_addr_const (file=0x75182960 <msvcrt!_iob+96>, x=0x209cce0)
    at ../../../../src/gcc-4.1.2/gcc/final.c:3242
#2  0x004f2925 in print_operand (file=0x75182960 <msvcrt!_iob+96>, x=0x209cce0, code=80)
    at ../../../../src/gcc-4.1.2/gcc/config/i386/i386.c:7485
#3  0x0057126c in output_operand (x=0x209cce0, code=<optimized out>) at ../../../../src/gcc-4.1.2/gcc/final.c:3206
#4  0x00571b79 in output_asm_insn (operands=0x9395a0 <recog_data>,
    template=0x801d0e <eliminables.16431+110> "call     %P0") at ../../../../src/gcc-4.1.2/gcc/final.c:3114
#5  output_asm_insn (template=0x801d0e <eliminables.16431+110> "call    %P0", operands=0x9395a0 <recog_data>)
    at ../../../../src/gcc-4.1.2/gcc/final.c:2958
#6  0x005728c0 in final_scan_insn (insn=0x20e19d8, file=0x75182960 <msvcrt!_iob+96>, optimize=0, nopeepholes=0,
    seen=0x28fc0c) at ../../../../src/gcc-4.1.2/gcc/final.c:2499
#7  0x00572ec4 in final (first=0x20de520, file=0x75182960 <msvcrt!_iob+96>, optimize=0)
    at ../../../../src/gcc-4.1.2/gcc/final.c:1617
#8  0x00572f87 in rest_of_handle_final () at ../../../../src/gcc-4.1.2/gcc/final.c:3949
#9  0x00526344 in execute_one_pass (pass=0x7a7160 <pass_final>) at ../../../../src/gcc-4.1.2/gcc/passes.c:827
#10 0x00527023 in execute_pass_list (pass=0x7a7160 <pass_final>) at ../../../../src/gcc-4.1.2/gcc/passes.c:859
#11 0x00527036 in execute_pass_list (pass=0x7a5ce0 <pass_postreload>) at ../../../../src/gcc-4.1.2/gcc/passes.c:860
#12 0x00527036 in execute_pass_list (pass=0x7a5d20 <pass_rest_of_compilation>)
    at ../../../../src/gcc-4.1.2/gcc/passes.c:860
#13 0x0052ef92 in tree_rest_of_compilation (fndecl=0x20b5b80) at ../../../../src/gcc-4.1.2/gcc/tree-optimize.c:419
#14 0x0040ce7c in c_expand_body (fndecl=0x20b5b80) at ../../../../src/gcc-4.1.2/gcc/c-decl.c:6689
#15 0x004a3962 in cgraph_expand_function (node=0x20b5c00) at ../../../../src/gcc-4.1.2/gcc/cgraphunit.c:1141
#16 0x004a3a4d in cgraph_assemble_pending_functions () at ../../../../src/gcc-4.1.2/gcc/cgraphunit.c:358
#17 cgraph_assemble_pending_functions () at ../../../../src/gcc-4.1.2/gcc/cgraphunit.c:341
#18 0x004a4169 in cgraph_finalize_function (decl=0x20b5b80, nested=0 '\000')
    at ../../../../src/gcc-4.1.2/gcc/cgraphunit.c:461
#19 0x0040d1dd in finish_function () at ../../../../src/gcc-4.1.2/gcc/c-decl.c:6658
#20 0x0044356e in c_parser_declaration_or_fndef (parser=0x1c4e168, fndef_ok=1 '\001', empty_ok=<optimized out>,
    nested=0 '\000', start_attr_ok=1 '\001') at ../../../../src/gcc-4.1.2/gcc/c-parser.c:1307
#21 0x00444d73 in c_parser_external_declaration (parser=0x1c4e168) at ../../../../src/gcc-4.1.2/gcc/c-parser.c:1071
#22 0x0044586c in c_parser_translation_unit (parser=0x1c4e168) at ../../../../src/gcc-4.1.2/gcc/c-parser.c:977
#23 c_parse_file () at ../../../../src/gcc-4.1.2/gcc/c-parser.c:6260
#24 0x00436904 in c_common_parse_file (set_yydebug=0) at ../../../../src/gcc-4.1.2/gcc/c-opts.c:1152
#25 0x00500adc in compile_file () at ../../../../src/gcc-4.1.2/gcc/toplev.c:991
#26 do_compile () at ../../../../src/gcc-4.1.2/gcc/toplev.c:1952
#27 toplev_main (argc=16, argv=0x1c21140) at ../../../../src/gcc-4.1.2/gcc/toplev.c:1984
#28 0x007a0758 in main (argc=16, argv=0x1c21140) at ../../../../src/gcc-4.1.2/gcc/main.c:35
(gdb)

Re: USER_LABEL_PREFIX appear on internal assembler labels

[Ian Lance Taylor]

On Tue, Jan 14, 2014 at 12:35 PM, Benjamin Burtscher
<benjamin.burtscher@gmx.at> wrote:
>
> I have a problem with internal assembler labels. We use #define USER_LABEL_PREFIX "_" in our i386 config to prefix global symbols.
> This is working, but the problem is that local internal assembler labels like ".L1" also get the prefix ("_.L1"), but not all of them. This produces unresolved symbols at the target.
> The -fleading-underscore switch produces the same problem.
>
> We can’t update to a newer version of GCC at the moment, because we use a third-party target platform.
>
> It would be great If you can tell me the interesting code lines where the problem could be so that I can fix it.
> I have attached 2 backtraces. In the first, the problem appears at a internal label. The second backtrace is the case where it works correctly with a global function.

You've got good backtraces.  You should look at each line in the
backtrace.  It ought to be fairly obvious what you need to change.  To
put it another way, if it's not obvious, you're going to have a lot of
trouble managing a private port of GCC.


> #0  assemble_name_raw (file=0x75182960 <msvcrt!_iob+96>, name=0x28f990 ".L19")
>     at ../../../../src/gcc-4.1.2/gcc/varasm.c:2034
> #1  0x0057148f in output_asm_label (x=<optimized out>) at ../../../../src/gcc-4.1.2/gcc/final.c:3184
> #2  0x00571d58 in output_asm_insn (operands=0x9395a0 <recog_data>,
>     template=0x8042e9 <eliminables.16431+9801> "%+j%C1  %l0") at ../../../../src/gcc-4.1.2/gcc/final.c:3092
> #3  output_asm_insn (template=0x8042e9 <eliminables.16431+9801> "%+j%C1 %l0", operands=0x9395a0 <recog_data>)
>     at ../../../../src/gcc-4.1.2/gcc/final.c:2958
> #4  0x005728c0 in final_scan_insn (insn=0x20e1850, file=0x75182960 <msvcrt!_iob+96>, optimize=0, nopeepholes=0,
>     seen=0x28fc0c) at ../../../../src/gcc-4.1.2/gcc/final.c:2499

For example, for this one you'll see that output_asm_label uses
ASM_GENERATE_INTERNAL_LABEL.  The definition of that is (probably) in
config/elfos.h.  Since ELF normally doesn't use a leading underscore,
there is no label prefix there.  Add a %U to that definition to get
the label prefix.

Ian