From: "Jan Djärv" <jan.h.d@swipnet.se>
To: David Caldwell <david@porkrind.org>
Cc: 18505-done@debbugs.gnu.org
Subject: bug#18505: 24.3.93; intermittent unexec failures when building on Mac OS X 10.10 beta, Xcode 6.0
Date: Sun, 21 Sep 2014 22:37:38 +0200 [thread overview]
Message-ID: <6AC8F693-97B2-418C-ACEB-8324D6529AC6@swipnet.se> (raw)
In-Reply-To: <541F13FD.5010302@porkrind.org>
Hi.
21 sep 2014 kl. 20:07 skrev David Caldwell <david@porkrind.org>:
> On 9/21/14 2:15 AM, Jan Djärv wrote:
>> Hello.
>>
>> 20 sep 2014 kl. 20:31 skrev David Caldwell <david@porkrind.org>:
>>
>>> On 9/20/14 8:31 AM, Jan Djärv wrote:
>>>> Hello.
>>>>
>>>> 19 sep 2014 kl. 06:13 skrev David Caldwell <david@porkrind.org>:
>>>>
>>>>> Hello,
>>>>>
>>>>> I tried to build the latest pretest on Mac OS X Yosemite Beta with the
>>>>> new Xcode 6.0 (GM) tools and ran into this error during the unexec step:
>>>>>
>>>>> unexec: not enough room for load commands for new __DATA segments
>>>>
>>>> Does it happen all the time or just some times?
>>>
>>> It depends on 2 variables: the number of load commands that need to be
>>> added (num_unexec_regions) and text_seg_lowest_offset.
>>>
>>> num_unexec_regions jumps around a lot, doing "make clean && make" over
>>> and over it'll be different every time. Somewhere between 12 and 34.
>>
>> What makes it do that? Some address randomization? Some other unknown bug?
>> I would expect num_unexec_regions to be the same for every make.
>
> I don't know. I would also expect num_unexec_regions to be the same. If
> it changes, it seems to mean the malloc behavior is different on every
> run. But yes, perhaps address space randomization could cause that to
> happen. I don't understand that part of the code well enough to
> speculate too much.
Me neither.
>
>> text_seg_lowest_offset could be address randomization, but if it stays somewhat constant, that can't be it.
>
> I just figured that out (and smacked my head because it was obvious).
> That changed when I changed headerpad. I got curious and did a binary
> search to figure out exactly how -headerpad affects
> text_seg_lowest_offset in my setup (all number hex):
>
> -headerpad text_seg_lowest_offset
> 0 -> 740 17a0
> 741 -> 1740 27a0
> 1741 -> ??? 37a0
>
> So, text_seg_lowest_offset directly correlate with -headerpad and ld is
> doing some sort of alignment.
Okay.
>
>> I've seen this failure before, but usually a new make works.
>> I'm trying to decide if this is emacs 24 or trunk material.
>
> I think it should go in both. It's really quite a low-risk change: the
> -headerpad option is well documented in ld, and the amount my patch adds
> gives an extra 1.5K of headroom on a 6M binary (.02%).
>
> I did a bunch of 'bzr log' searches to understand the nature of the
> -headerpad setting and it appears to not have been touched since 2006
> (in the 32 bit era). I believe that is why the comment in configure is
> incorrect: load commands may have been 56 bytes on 32 bit archs, but
> they are 78 bytes on my 64 bit computer (which is all current Macs going
> forward).
I checked it in in the 24-branch.
>
>> Is there a way to dynamically react to these changes and adjust headerpad_extra dynamically at dump time?
>
> Unfortunately the -headerpad is specified during link time so to change
> it dynamically would require re-linking after unexec-ing. That's a large
> Makefile change to get that all working correctly.
And possibly overkill.
Thanks,
Jan D.
prev parent reply other threads:[~2014-09-21 20:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-19 4:13 bug#18505: 24.3.93; intermittent unexec failures when building on Mac OS X 10.10 beta, Xcode 6.0 David Caldwell
2014-09-20 15:31 ` Jan Djärv
2014-09-20 18:31 ` David Caldwell
2014-09-21 9:15 ` Jan Djärv
2014-09-21 18:07 ` David Caldwell
2014-09-21 20:37 ` Jan Djärv [this message]
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=6AC8F693-97B2-418C-ACEB-8324D6529AC6@swipnet.se \
--to=jan.h.d@swipnet.se \
--cc=18505-done@debbugs.gnu.org \
--cc=david@porkrind.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.