From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============1704402501306966467=="
MIME-Version: 1.0
From: Crestez Dan Leonard <cdleonard@gmail.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: MIPS and -msym32
Date: Tue, 22 Jul 2014 17:44:48 +0300
Message-ID: <53CE78E0.1050905@gmail.com>

--===============1704402501306966467==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

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. H=
ere is the link to the patches on top of 1.6:
	https://sourceware.org/git/gitweb.cgi?p=3Dsystemtap.git;a=3Dlog;h=3Drefs/h=
eads/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 poi=
nter size of 4, even though the file is 64bit. In theory this can be disabl=
ed by passing KBUILD_SYM32=3Dno to the kernel make commandline. This is a b=
ad idea. It would disable some optimizations which have been enabled on mip=
s for many years. I actually tried to do it locally but it broke module loa=
ding 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_d=
iecu to determine max_fetch_size. This caused an error like "semantic error=
: single register too big for fetch/store ???: identifier '$data' at ..." f=
or 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 =3D CUDIE (die->cu);
 =

   if (address_sizep !=3D NULL)
+  {
     *address_sizep =3D die->cu->address_size;
+    /* Hack: */
+    if (1)
+    {
+      struct Elf *elf =3D die->cu->dbg->elf;
+      GElf_Ehdr ehdr_mem;
+      GElf_Ehdr* ehdr =3D gelf_getehdr (elf, &ehdr_mem);
+      if (ehdr &&
+              ehdr->e_machine =3D=3D EM_MIPS &&
+              ehdr->e_ident[EI_CLASS] =3D=3D ELFCLASS64)
+      {
+        *address_sizep =3D 8;
+      }
+    }
+  }
   if (offset_sizep !=3D NULL)
     *offset_sizep =3D die->cu->offset_size;

This is obviously evil. What is worse is that -msym32 seems to break system=
tap address mapping. Earlier I had to do the following hack inside systemta=
p.

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_funcna=
me,
       else
         {
           assert (has_kernel || has_module);
+          if (1)
+            {
+              Dwarf_Addr bias;
+              Elf* elf =3D (dwarf_getelf (dwfl_module_getdwarf (dw.module,=
 &bias))
+                 ?: dwfl_module_getelf (dw.module, &bias));
+              GElf_Ehdr ehdr_mem;
+              GElf_Ehdr* em =3D gelf_getehdr (elf, &ehdr_mem);
+              int elf_machine =3D em->e_machine;
+              if (elf_machine =3D=3D EM_MIPS)
+                {
+                  if (sess.verbose > 1)
+                    clog << "Hack reloc=3D" << hex << reloc_addr
+                      << " from addr=3D" << hex << addr;
+                  reloc_addr =3D addr - 0xc0000400;
+                }
+            }
           results.push_back (new dwarf_derived_probe(funcname, filename, l=
ine,
                                                      module, reloc_section=
, addr, reloc_addr,
                                                      *this, scope_die));

At the time I did the hack I was unaware of -msym32, I just wanted somethin=
g to work. If I compile with KBUILD_SYM32=3Dno it seems that the above hack=
 might no longer be necessary (the addresses "look" right). I can't actuall=
y test the generated probes because my system won't boot with KBUILD_SYM32=
=3Dno.

Apparently the gcc folks decided that this -msym32 behavior was too confusi=
ng 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

--===============1704402501306966467==--