Fix Issue 4181 - GDB prints wrong value of TLS variables

[tramker]

https://issues.dlang.org/show_bug.cgi?id=4181

Add DW_OP_GNU_push_tls_address to dwarf debug info for tls vars and also add offset to the address in append_addr() which fixes shared global vars.

I'm novice in dmd and dwarf hacking, so please review thoroughly.

Works for me on Debian wheezy x86 and x86_64, dmd 2.066 and master, gdb 7.8.50.

[MartinNowak]

I64 ? R_X86_64_DTPOFF32 : RI_TYPE_TLS_LDO_32

[MartinNowak]

I want to support newer Dwarf versions at some point.
Could you add a #define DWARF_VERSION 2 in the header and conditionally use the standard TLS op?
http://llvm.org/bugs/show_bug.cgi?id=18423

[MartinNowak]

Shouldn't this be R_X86_64_DTPOFF64?

[MartinNowak]

I still get Cannot access memory at address 0x7ffff8434e50 errors.

[tramker]

On Wed, 8 Oct 2014, Martin Nowak wrote:

I still get Cannot access memory at address 0x7ffff8434e50 errors.

What system and gdb version ? What info address 'module.tlsvar' shows ?

[MartinNowak]

I just broke your pull merging #3814, you simply have to replace the RI_TYPE_ constants with R_386_.

[MartinNowak]

GNU gdb (GDB) Fedora 7.7.1-19.fc20

(gdb) p 'test.x'
Cannot access memory at address 0x7ffff8434e50
(gdb) p _D4test1xi
Cannot access memory at address 0x7ffff8434e50
(gdb) info address 'test.x'
No symbol "'test.x'" in current context.
(gdb) info address _D4test1xi
Symbol "test.x()" is a thread-local variable at offset 0x45e6f0 in the thread-local storage for `/home/dawg/Code/D/test'.

[MartinNowak]

The offset 0x45e6f0 is incorrect that is an absolute value of the TLS image, it should be 0x10 I guess.

readelf --segments test

  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  TLS            0x000000000005d6e0 0x000000000045e6e0 0x000000000045e6e0
                 0x0000000000000010 0x0000000000000060  R      10

[tramker]

Shouldn't this be R_X86_64_DTPOFF64?

I've tried, but it produces an error (absolute address) similar to your report.

Edit: R_X86_64_DTPOFF32 is a workaround for ld.bfd v2.22. Recent binutils (2.25.51, probably since 2.24) work with R_X86_64_DTPOFF64

[tramker]

The offset 0x45e6f0 is incorrect that is an absolute value of the TLS image, it should be 0x10 I guess.

This is caused by ld.gold linker. ld.bfd works, I've tried it on Fedora.

[MartinNowak]

Sorry for the noise, the problem only happened with R_X86_64_DTPOFF64 instead of R_X86_64_DTPOFF32.

[MartinNowak]

Only applies to ELF.
Also there is no need to add all those dwarf_appreladdr_tls functions when they are only used once.
I'd propose this instead.

#if ELFOBJ
            assert(s->Sxtrnnum);
            if (s->Sfl == FLtlsdata)
            {
                if (I64)
                {
                    infobuf->writeByte(DW_OP_const8u);
                    ElfObj::addrel(infoseg, infobuf->size(), R_X86_64_DTPOFF32, s->Sxtrnnum, 0);
                    infobuf->write64(0);
                }
                else
                {
                    infobuf->writeByte(DW_OP_const4u);
                    ElfObj::addrel(infoseg, infobuf->size(), R_386_TLS_LDO_32, s->Sxtrnnum, 0);
                    infobuf->write32(0);
                }
                infobuf->writeByte(0xe0);            // DW_OP_GNU_push_tls_address
            }
            else
#endif
            {
                infobuf->writeByte(DW_OP_addr);
                dwarf_addrel(infoseg,infobuf->size(),s->Sseg);
                append_addr(infobuf, s->Soffset);    // address of global
            }

[tramker]

Redone based on Martin's suggestions. Looks much cleaner.

[MartinNowak]

Great, thanks a lot.

[justanotheranonymoususer]

Won't this break DDMD? @yebblies

[yebblies]

Nope, because the backend doesn't get converted.