Support x86_64 linux in client code

[GoogleCodeExporter]

I try to use breakpad with full 64 bits environment but for the moment I
cannot write a correct minidump, more precisely information about threads
are not written.

There are many problems. The first one is that the registers are not the
same as used in minidump_generator and it needs methods to write x86_64
contexts. 
But my actual problem is that the function GetRegisters of linux_thread
doesn't work. The regs doesn't contain the expected values. I obtain only 0
for the ebp value (called rbp on x86_64).

Could someone help me to solve this problem ? it seems that ptrace is
compatible with x86_64 but there is maybe a particular way to use it.

I use the last update of the source of breakpad with gcc 4.1.3 and on
debian 2.6.22 lenny 

Original issue reported on code.google.com by nmarte...@gmail.com on 24 Jan 2008 at 12:41

[GoogleCodeExporter]

ok after more investigation, I found on different sources that the are 
differences
between x86 and x86_64 to manage the stack. By default, rbp is not used ( or 
used as
a general purpose register ) and to walk through the stack only rsp is 
necessary. It
implies that the problem maybe do not came from GetRegisters but from 
GetNextFrame.
Returning the value pointed by the address like for x86 is not correct.

http://blogs.sun.com/eschrock/entry/debugging_on_amd64_part_two

Original comment by nmarte...@gmail.com on 25 Jan 2008 at 2:32

[GoogleCodeExporter]

We don't currently have x86_64 support on the client.  Liu Li has been looking 
into this.

Original comment by ted.mielczarek on 26 Jan 2008 at 8:01

[GoogleCodeExporter]

Original comment by ted.mielczarek on 21 Aug 2008 at 4:02

• Changed title: Support x86_64 linux in client code
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Thanks for the modification, now the library could be compiled without any 
errors.

anyway when I try to compile the dump_syms tool, there is an error in the file
src/common/linux/dump_symbols.cc in method FixAddress there is an error since 
the
program try to cast a void* in a Word (which is mapped in Elf64_Word) and this 
cast
implies a lost of precision. In a 64bits architecture, void* is on 64bits but
Elf64_Word is 32.

On 64bits architecture the type using 64bits is Xword.

Original comment by nmarte...@gmail.com on 28 Aug 2008 at 1:39

[GoogleCodeExporter]

Hi, the fix for this seems to be to use Xword instead of Word, which is 
typedefed to
the right thing (namely, uint64_t). I can get further along in the compilation 
this
way, but I fail later with 

/home/jordi/coding/vcs/qutecom-2.2/libs/3rdparty/googlebreakpad/src/client/linux
/handler/linux_thread.h:152:
error: ‘user_fpxregs_struct’ has not been declared

(Yeah, I'm actually trying to compile qutecom). I see someone else has has run 
into
this problem recently too.

Original comment by jord...@gmail.com on 13 Nov 2008 at 7:36

[GoogleCodeExporter]

I couldn't quite let this go, so I kept on modifying stuff for 64bits as I went
along. Somethings are rather obvious, but later on I get on to sigcontext stuff 
which
I don't know, since it refers to the registers in 64bit machines, and I don't 
know
what the equivalent registers in 64bits are, or if they even are exactly 
equivalent.

Also, I'm not sure how to make this code both 32bit and 64bit correct. I am 
pretty
sure my modifications will break on a 32bit system, even if I manage to figure 
out
what the correct settings should be on 64bit. :-(

Original comment by jord...@gmail.com on 13 Nov 2008 at 8:20

[GoogleCodeExporter]

Liu Li had done some work along these lines, I don't know if he has a patch 
anywhere.
The bugs you're hitting can be fixed, but the biggest problem he hit was that we
currently rely on being able to walk the stack client-side to gather some info, 
and
that's not possible on x86-64, as code is built with omit-frame-pointer by 
default.

Original comment by ted.mielczarek on 14 Nov 2008 at 2:29

[GoogleCodeExporter]

I have a patch, but it can't solve everything.

As mentioned by Ted, the problem is we need to walk the stack when crash 
happens,
which currently heavily relying on frame pointers. On x86_64, there is no 
universal
way of doing that since "omit-frame-pointer" is the default option of gcc, and 
most
of the libs linked in don't have frame pointers at all.

Anyway, I will give a patch, sometimes it will work for X86_64, but not all the 
time.
The good news is it works for 32bit:-)

Original comment by lul...@gmail.com on 15 Nov 2008 at 5:09

Attachments:

• linux_x86_64.patch

[GoogleCodeExporter]

This got fixed on trunk recently. I can catch crashes on x86-64 Linux, generate
dumps, and process them.

Original comment by ted.mielczarek on 9 Dec 2009 at 8:47

• Changed state: Fixed