From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH v9] Build process uses script to add CFI directives to x86 asm
Date: Wed, 8 Jul 2015 10:11:12 -0400 [thread overview]
Message-ID: <20150708141112.GM1173@brightrain.aerifal.cx> (raw)
In-Reply-To: <CACsECNedQxgEGcpiPwZxyhoP6G2JPXKE12GrC_C4ux6qikjDfA@mail.gmail.com>
On Wed, Jul 08, 2015 at 09:54:55AM +0200, Alex wrote:
> On Wed, Jul 8, 2015 at 9:13 AM, Alex <alexinbeijing@gmail.com> wrote:
> > On Wed, Jul 8, 2015 at 4:36 AM, Rich Felker <dalias@libc.org> wrote:
> >> On Tue, Jul 07, 2015 at 08:27:46PM +0200, Alex wrote:
> >>> > 2. I suspect a dynamic-linked binary without the corresponding libc.so
> >>> > is not useful. Do you want the static-linked binary with a reference
> >>> > to pthread_cancel added?
> >>>
> >>> I want to see the DWARF data, and in this case it should be in
> >>> libc.so, not in canbt. But let me test under conditions more similar
> >>> to yours first.
> >>
> >> I'm attaching the static a.out which exhibits the problem, and sending
> >> this off-list since it's (mildly) big. I can send libc.so if you
> >> prefer but I think the static version is sufficient to see the
> >> problem.
> >
> > Thanks. The problem was nothing to do with differences in our build
> > environments. The problem was that in src/thread/i386/syscall_cp.s,
> > _syscall_cp_asm "falls through" into __cp_begin.
> >
> > The CFI generation process assumes that each "global" label is a call
> > target, and hence when a global label is reached, the stack frame
> > offset should be 4. It assumes that we must have reached the current
> > point from a CALL, and that the return address should be on the top of
> > the stack.
> >
> > In this case, __cp_begin is NOT a call target. (It is used in
> > pthread_cancel.c:cancel_handler, which checks whether a saved
> > instruction pointer value is between __cp_begin and __cp_end.)
> >
> > I will amend the script so that it must see a ".global" directive
> > *and* a ".type @function" directive before it assumes that a label is
> > an entry point for C function calls.
I'm a little bit skeptical of this approach, but it probably does work
in practice. Stack pointer should be non-adjusted at any callable
external symbol. The exceptions are the __cp_* labels and they (at
present) are not function-type, but may need to be function-type on
arm once we support thumb2 asm because I think the thumb bit gets lost
without function-type (but maybe it doesn't matter). In any case that
doesn't affect x86.
> A couple questions:
>
> drem(), dremf(), and vfork() are declared as ".type @function", but
> not ".global". Rather, they use ".weak" directives. Are such labels to
> be considered entry points?
Yes, they are entry points, and I think having vfork be weak is wrong
anyway (it was from back when we had other code in musl calling
__vfork, which was a bad idea).
> Then there are some labels which are declared as ".global" and
> ".hidden", like __memcpy_fwd, __exp2l, and ___setjmp. It looks like
> when any of those 3 are reached, there should be a return address on
> top of the stack. What would you think of adding a ".type @function"
> declaration for those 3, so that the CFI generation script will treat
> them as "functions"?
Do these matter? The exact same address is already an entry point
via the other public name(s) you're supposed to use for it.
Rich
next prev parent reply other threads:[~2015-07-08 14:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-23 19:18 Alex Dowad
2015-06-23 21:52 ` Rich Felker
2015-06-24 5:33 ` Alex
2015-06-28 2:58 ` Rich Felker
2015-07-08 14:16 ` Rich Felker
2015-07-08 14:25 ` Alex
2015-07-09 5:00 ` Rich Felker
2015-07-07 3:39 ` Rich Felker
2015-07-07 5:45 ` Alex
2015-07-07 13:21 ` Rich Felker
2015-07-07 16:40 ` Alex
2015-07-07 18:15 ` Rich Felker
2015-07-07 18:27 ` Alex
[not found] ` <20150708023638.GJ1173@brightrain.aerifal.cx>
2015-07-08 7:13 ` Alex
2015-07-08 7:54 ` Alex
2015-07-08 14:11 ` Rich Felker [this message]
2015-07-08 14:24 ` Alex
-- strict thread matches above, loose matches on Subject: below --
2015-06-15 6:45 Alex Dowad
2015-06-20 21:11 ` Rich Felker
2015-06-21 5:00 ` Alex
2015-06-21 5:05 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150708141112.GM1173@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).