From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12532 invoked by alias); 22 Jul 2014 14:45:12 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 12516 invoked by uid 89); 22 Jul 2014 14:45:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f181.google.com Received: from mail-we0-f181.google.com (HELO mail-we0-f181.google.com) (74.125.82.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 22 Jul 2014 14:45:09 +0000 Received: by mail-we0-f181.google.com with SMTP id k48so8185948wev.12 for ; Tue, 22 Jul 2014 07:45:04 -0700 (PDT) X-Received: by 10.180.92.73 with SMTP id ck9mr15700150wib.54.1406040302875; Tue, 22 Jul 2014 07:45:02 -0700 (PDT) Received: from [10.205.20.121] ([109.100.41.154]) by mx.google.com with ESMTPSA id wd7sm1460576wjc.36.2014.07.22.07.45.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 07:45:00 -0700 (PDT) Message-ID: <53CE78E0.1050905@gmail.com> Date: Tue, 22 Jul 2014 14:45:00 -0000 From: Crestez Dan Leonard User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: elfutils-devel@lists.fedorahosted.org., systemtap@sourceware.org Subject: MIPS and -msym32 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-q3/txt/msg00071.txt.bz2 Hello, I've been playing around with systemtap on mips. I used the elfutils mips patch from debian: http://sources.debian.net/src/elfutils/0.159-4/debian/patches/mips_backend.diff For systemtap I ported some old patches from cisco on top of release 2.5. Here is the link to the patches on top of 1.6: https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=log;h=refs/heads/systemtap-1.6-cisco-patches One of the issues I encountered is that by default 64-bit mips kernels are compiled with -msym32. This causes gcc to emit dwarf information with a pointer size of 4, even though the file is 64bit. In theory this can be disabled by passing KBUILD_SYM32=no to the kernel make commandline. This is a bad idea. It would disable some optimizations which have been enabled on mips for many years. I actually tried to do it locally but it broke module loading and I was unable to boot. The generated dwarf files confuse systemtap is multiple ways. When fetching some parameters systemtap relies on address_size from dwarf_diecu to determine max_fetch_size. This caused an error like "semantic error: single register too big for fetch/store ???: identifier '$data' at ..." for an unsigned long variable. Here is a hack I used to get around this: --- a/libdw/dwarf_diecu.c +++ b/libdw/dwarf_diecu.c @@ -47,7 +47,22 @@ dwarf_diecu (die, result, address_sizep, offset_sizep) *result = CUDIE (die->cu); if (address_sizep != NULL) + { *address_sizep = die->cu->address_size; + /* Hack: */ + if (1) + { + struct Elf *elf = die->cu->dbg->elf; + GElf_Ehdr ehdr_mem; + GElf_Ehdr* ehdr = gelf_getehdr (elf, &ehdr_mem); + if (ehdr && + ehdr->e_machine == EM_MIPS && + ehdr->e_ident[EI_CLASS] == ELFCLASS64) + { + *address_sizep = 8; + } + } + } if (offset_sizep != NULL) *offset_sizep = die->cu->offset_size; This is obviously evil. What is worse is that -msym32 seems to break systemtap address mapping. Earlier I had to do the following hack inside systemtap. diff --git a/tapsets.cxx b/tapsets.cxx index 4e42403..94ee230 100644 --- a/tapsets.cxx +++ b/tapsets.cxx @@ -1265,6 +1265,22 @@ dwarf_query::add_probe_point(const string& dw_funcname, else { assert (has_kernel || has_module); + if (1) + { + Dwarf_Addr bias; + Elf* elf = (dwarf_getelf (dwfl_module_getdwarf (dw.module, &bias)) + ?: dwfl_module_getelf (dw.module, &bias)); + GElf_Ehdr ehdr_mem; + GElf_Ehdr* em = gelf_getehdr (elf, &ehdr_mem); + int elf_machine = em->e_machine; + if (elf_machine == EM_MIPS) + { + if (sess.verbose > 1) + clog << "Hack reloc=" << hex << reloc_addr + << " from addr=" << hex << addr; + reloc_addr = addr - 0xc0000400; + } + } results.push_back (new dwarf_derived_probe(funcname, filename, line, module, reloc_section, addr, reloc_addr, *this, scope_die)); At the time I did the hack I was unaware of -msym32, I just wanted something to work. If I compile with KBUILD_SYM32=no it seems that the above hack might no longer be necessary (the addresses "look" right). I can't actually test the generated probes because my system won't boot with KBUILD_SYM32=no. Apparently the gcc folks decided that this -msym32 behavior was too confusing and changed it to generate dwarf with a pointer size of 8: https://gcc.gnu.org/ml/gcc/2009-01/msg00611.html In the future this might not matter, but my cross-compiler is based on gcc-4.3.3. I'm posting this here because maybe somebody has a better idea about how to deal with this strange flavor of dwarf. If this could be detected and handled inside systemtap fully then maybe you could apply the patches. Elfutils seems mostly blameless to me, it's just reading the information that GCC wrote. Regards, Leonard