libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] FreeBSD port


From: Konstantin Belousov
Subject: Re: [Libunwind-devel] FreeBSD port
Date: Mon, 5 Apr 2010 23:25:12 +0300
User-agent: Mutt/1.4.2.3i

On Mon, Apr 05, 2010 at 11:36:14AM -0700, Arun Sharma wrote:
> On Mon, Apr 5, 2010 at 7:03 AM, Konstantin Belousov <address@hidden>wrote:
> 
> >
> > It shall not appear in config.h. What I did is created a macro that
> > accept a list of PTRACE_* or PT_* identifiers and generates proper
> > AC_CHECK_DECLS() calls. The individual HAVE_DECL_PTRACE_something or
> > HAVE_DECL_PT_something defines are still there.
> >
> 
> Compilation fails on Linux as follows:
> 
> ptrace/_UPT_access_fpreg.c:104:2: error: #error Fix me
> make[2]: *** [ptrace/_UPT_access_fpreg.o] Error 1
> 
> i.e. HAVE_DECL_PTRACE_* doesn't seem to be defined anywhere.
I applied your patch from later followup. Thanks !

> 
> 
> > After I saw your reorganisation for sigframe handling code, I think
> > that the similar approach may work well there too.
> >
> >
> There may be some opportunities for code sharing between OSes with common
> roots. So I'd like to defer code reorganization for now.
Ok.

> 
> Could you move the get_scratch_loc() code to OS specific files as well? I
> can help test on Linux once you're done.
Done. I also moved uc_addr() and x86_local_resume().

> 
> Some more thoughts about the freebsd port:
> 
> * dl_iterate_phdr() is not async signal safe on linux (it takes some libdl
> internal locks). So it's unsafe to call from libunwind. But we still do,
> because there is no better alternative. Is this the case for FreeBSD as
> well?
Short answer is that dl_iterate_phdr() is not async-signal-safe on
FreeBSD as well.

Slightly longer and IMO amusing story is that it is mostly safe if
threading library is not loaded into the process.

> 
> * cursor->validate implementation
> 
> libunwind uses msync() which is not bulletproof i.e. it's not directly
> equivalent to access_ok(VERIFY_READ,...) in the kernel. Does FreeBSD have a
> better alternative?
mincore(2) can be used, it will return errno == ENOMEM when range is
not mapped. It would walk some internal structures to determine the
page residency. But at least mincore(2) does not initiate a stray write.

> 
> If there are libc interfaces to enumerate valid stack addresses, the
> validation can be implemented as an address range check.
Not that I am aware of. Thread library does dirty trick on the main
thread stack, unmapping the page at the bottom of the default thread
stack size. This is done to prevent automatic stack grow for main thread
up to RLIMIT_STACK, that is usually much bigger that default thread
stack size.

Thank you.

Attachment: pgpFG4frfvPQN.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]