kamlesh kumar via llvm-dev
2019-Dec-10 11:29 UTC
[llvm-dev] aarch64 do not generate debug info for tls var
GCC's behavior matches LLVM. so should we leave it? On Tue, Dec 10, 2019 at 12:54 PM David Blaikie <dblaikie at gmail.com> wrote:> What does GCC do? > > On Mon, Dec 9, 2019 at 10:25 PM kamlesh kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Devs, >> >> consider below testcase >> $cat test.c >> __thread int mtls=1; >> void foo(){ >> mtls++; >> } >> >> it emits this debug info for mtls >> >> 0x0000002a: DW_TAG_variable >> DW_AT_name ("mtls") >> DW_AT_type (0x00000035 "int") >> DW_AT_external (true) >> DW_AT_decl_file ("test.c") >> DW_AT_decl_line (1) >> >> which does not contain DW_AT_Location. >> >> Currently, aarch64 does not emit DW_AT_Location for TLS variables. >> I could see at this line, it says some restriction in aarch64 elf abi. >> >> https://github.com/llvm-mirror/llvm/blob/master/lib/Target/AArch64/AArch64TargetObjectFile.cpp#L24 >> >> I would like to know community thoughts on this and is there any other >> way to tackle this, or we simply can not debug TLS variables for this >> architecture? >> >> >> ./Kamlesh >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191210/08ba7177/attachment.html>
Peter Smith via llvm-dev
2019-Dec-10 11:45 UTC
[llvm-dev] aarch64 do not generate debug info for tls var
On Tue, 10 Dec 2019 at 11:30, kamlesh kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > GCC's behavior matches LLVM. > so should we leave it? >There is some more information in https://reviews.llvm.org/D43860 . It has been some time since I looked at this, so my memory is hazy. As I understand it there isn't a way to express the relocation in debug info, all the existing TLS relocations are defined for instructions with small immediate field. If we use a non-TLS relocation linkers will refuse to link the binary as only TLS relocations are permitted to relocate against TLS symbols. The AArch64 ABI https://developer.arm.com/docs/ihi0056/f/elf-for-the-arm-64-bit-architecture-aarch64-abi-2019q2-documentation has a contact email on the front page. If your reading matches D43860 it may be worth contacting the email address describing the problem. With a new relocation type, and support in compilers and linkers this may be possible to address. Peter> On Tue, Dec 10, 2019 at 12:54 PM David Blaikie <dblaikie at gmail.com> wrote: >> >> What does GCC do? >> >> On Mon, Dec 9, 2019 at 10:25 PM kamlesh kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Hi Devs, >>> >>> consider below testcase >>> $cat test.c >>> __thread int mtls=1; >>> void foo(){ >>> mtls++; >>> } >>> >>> it emits this debug info for mtls >>> >>> 0x0000002a: DW_TAG_variable >>> DW_AT_name ("mtls") >>> DW_AT_type (0x00000035 "int") >>> DW_AT_external (true) >>> DW_AT_decl_file ("test.c") >>> DW_AT_decl_line (1) >>> >>> which does not contain DW_AT_Location. >>> >>> Currently, aarch64 does not emit DW_AT_Location for TLS variables. >>> I could see at this line, it says some restriction in aarch64 elf abi. >>> https://github.com/llvm-mirror/llvm/blob/master/lib/Target/AArch64/AArch64TargetObjectFile.cpp#L24 >>> >>> I would like to know community thoughts on this and is there any other way to tackle this, or we simply can not debug TLS variables for this architecture? >>> >>> >>> ./Kamlesh >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
kamlesh kumar via llvm-dev
2019-Dec-10 12:56 UTC
[llvm-dev] aarch64 do not generate debug info for tls var
Thank you @Peter for the Info. On Tue, Dec 10, 2019 at 5:15 PM Peter Smith <peter.smith at linaro.org> wrote:> On Tue, 10 Dec 2019 at 11:30, kamlesh kumar via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > GCC's behavior matches LLVM. > > so should we leave it? > > > > There is some more information in https://reviews.llvm.org/D43860 . It > has been some time since I looked at this, so my memory is hazy. As I > understand it there isn't a way to express the relocation in debug > info, all the existing TLS relocations are defined for instructions > with small immediate field. If we use a non-TLS relocation linkers > will refuse to link the binary as only TLS relocations are permitted > to relocate against TLS symbols. > > The AArch64 ABI > > https://developer.arm.com/docs/ihi0056/f/elf-for-the-arm-64-bit-architecture-aarch64-abi-2019q2-documentation > has a contact email on the front page. If your reading matches D43860 > it may be worth contacting the email address describing the problem. > With a new relocation type, and support in compilers and linkers this > may be possible to address. > > Peter > > > On Tue, Dec 10, 2019 at 12:54 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> What does GCC do? > >> > >> On Mon, Dec 9, 2019 at 10:25 PM kamlesh kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >>> > >>> Hi Devs, > >>> > >>> consider below testcase > >>> $cat test.c > >>> __thread int mtls=1; > >>> void foo(){ > >>> mtls++; > >>> } > >>> > >>> it emits this debug info for mtls > >>> > >>> 0x0000002a: DW_TAG_variable > >>> DW_AT_name ("mtls") > >>> DW_AT_type (0x00000035 "int") > >>> DW_AT_external (true) > >>> DW_AT_decl_file ("test.c") > >>> DW_AT_decl_line (1) > >>> > >>> which does not contain DW_AT_Location. > >>> > >>> Currently, aarch64 does not emit DW_AT_Location for TLS variables. > >>> I could see at this line, it says some restriction in aarch64 elf abi. > >>> > https://github.com/llvm-mirror/llvm/blob/master/lib/Target/AArch64/AArch64TargetObjectFile.cpp#L24 > >>> > >>> I would like to know community thoughts on this and is there any other > way to tackle this, or we simply can not debug TLS variables for this > architecture? > >>> > >>> > >>> ./Kamlesh > >>> > >>> > >>> > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> llvm-dev at lists.llvm.org > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191210/97d5e7f9/attachment.html>