This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [PATCH] Fix AMD64 backtrace

From: Jakub Jelinek <jakub at redhat dot com>
To: Andreas Jaeger <aj at suse dot de>
Cc: Glibc hackers <libc-hacker at sources dot redhat dot com>
Date: Sat, 10 Jan 2004 18:50:49 +0100
Subject: Re: [PATCH] Fix AMD64 backtrace
References: <20040108134216.GE6413@sunsite.ms.mff.cuni.cz> <m33candbth.fsf@gromit.moeb> <m37jzzbn36.fsf@gromit.moeb>
Reply-to: Jakub Jelinek <jakub at redhat dot com>

On Sat, Jan 10, 2004 at 08:49:49PM +0100, Andreas Jaeger wrote:
> Andreas Jaeger <aj@suse.de> writes:
> 
> > Jakub Jelinek <jakub@redhat.com> writes:
> > [...]
> >>> libc/sysdeps/x86_64/__longjmp.S
> >
> > What's the best way to handle the destroying of the registers with
> > CFI?  Should we just mark the registers with "cfi_undefined"?
> 
> I'm appending a proposed patch for __longjmp.S.  Or can anybody
> envision a better way doing this?

Cannot you from the first movq ***,%rbx pretend you're
already at the jmpq %*rdx instruction, ie. unwind to the
longjmp target?
Write in the unwind info where to fetch %rbp, %r12..%r15,
ra etc. from?

	Jakub

Follow-Ups:
- Re: [PATCH] Fix AMD64 backtrace
  - From: Andreas Jaeger

References:
- [PATCH] Fix AMD64 backtrace
  - From: Jakub Jelinek
- Re: [PATCH] Fix AMD64 backtrace
  - From: Andreas Jaeger
- Re: [PATCH] Fix AMD64 backtrace
  - From: Andreas Jaeger

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]