search for: linfo_str

Hi, When I use -S to generate an assembly file (ARM target) .Linfo_string symbols are generated. I would expect the clang assembler to treat these as locals (i.e not appear in the object file) but they do. Using the GNU assembler the symbols don't appear in the object file. Why are .Linfo_string symbols treated differently to other local labels by the clang a...

...>> leaves no assembler-local strings, but for some reason going via -S >> does. I've not investigated further I'm afraid. > Sorry, had somehow replied off list: > > This reduces to > > .section .debug_str,"MS",%progbits,1 > .Linfo_string8: > .long .Linfo_string8 > > the difference comes from ELFObjectWriter::shouldRelocateWithSymbol. In > particular > > // It looks like gold has a bug (http://sourceware.org/PR16794) and can > // only handle section relocations to mergeab...

On 3 May 2017 at 08:01, Rafael Avila de Espindola via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Can you provide a .s file that shows the difference? I managed to reproduce it by compiling 'char *var = "whatever";' in debug mode (so clang -target arm-none-eabi tmp.c -g"). Direct compile leaves no assembler-local strings, but for some reason going via -S does.

...rmv7l-linux-gnueabihf main.cpp and then look at the symbols readelf -s main.o there will be a number of similar entries (showing one entry only here for conciseness): Num: Value Size Type Bind Vis Ndx Name 7: 00000062 0 NOTYPE LOCAL DEFAULT 9 These are the .Linfo_string<index> symbols whose names are skipped due to r236642. If we now link it clang++ -o main.out --target=armv7l-linux-gnueabihf main.o all the symbols get through to the final binary: readelf -s main.out Num: Value Size Type Bind Vis Ndx Name 73...

...its > .section .debug_macinfo,"", at progbits > .section .debug_line,"", at progbits > Lsection_line: > .section .debug_loc,"", at progbits > .section .debug_pubtypes,"", at progbits > .section .debug_str,"MS", at progbits,1 > Linfo_string: > .section .debug_ranges,"", at progbits > Ldebug_range: > .section .debug_loc,"", at progbits > Lsection_debug_loc: > .text > Ltext_begin: > .data > .file 1 "test.c" > .text > .global main > .type main, at function > main:...

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

Hi, all I ported llvm backend and lldb recently. Both tools can basically work. lldb is able to debug programs in asm style and frame unwinding is OK. But "frame variable XX" does not work because lldb is not able to determine the address of XX from debug info. Can someone give any clue? Thanks in advance. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML

...ion .debug_line,"", at progbits > > Lsection_line: > > .section .debug_loc,"", at progbits > > .section .debug_pubtypes,"", at progbits > > .section .debug_str,"MS", at progbits,1 > > Linfo_string: > > .section .debug_ranges,"", at progbits > > Ldebug_range: > > .section .debug_loc,"", at progbits > > Lsection_debug_loc: > > .text > > Ltext_begin: > > .data > > .file 1 "t...