svn commit: r305353 - in head/sys/boot: i386 i386/boot0 i386/boot2 i386/btx/btx i386/btx/btxldr i386/cdboot i386/gptboot i386/gptzfsboot i386/mbr i386/pmbr i386/pxeldr i386/zfsboot pc98 pc98/boot0 ...

[Warner Losh]

On Mon, Sep 26, 2016 at 11:00 AM, John Baldwin <jhb at freebsd.org> wrote:
> On Saturday, September 24, 2016 02:56:05 PM Warner Losh wrote:
>> On Fri, Sep 23, 2016 at 4:17 PM, Allan Jude <allanjude at freebsd.org> wrote:
>> > On 09/03/16 11:26 AM, Warner Losh wrote:
>> >> Author: imp
>> >> Date: Sat Sep  3 15:26:28 2016
>> >> New Revision: 305353
>> >> URL: https://svnweb.freebsd.org/changeset/base/305353
>> >>
>> >> Log:
>> >>   Don't use -N to set the OMAGIC with data and text writeable and data
>> >>   not page aligned. To do this, use the ld script gnu ld installs on my
>> >>   system.
>> >>
>> >>   This is imperfect: LDFLAGS_BIN and LD_FLAGS_BIN describe different
>> >>   things. The loader script could be better named and take into account
>> >>   other architectures. And having two different mechanisms to do
>> >>   basically the same thing needs study. However, it's blocking forward
>> >>   progress on lld, so I'll work in parallel to sort these out.
>> >>
>> >>   Differential Revision: https://reviews.freebsd.org/D7409
>> >>   Reviewed by: emaste
>> >>
>> >
>> > This breaks booting on my Lenovo laptop. The BTX client crashes and
>> > dumps the registers.
>> >
>> > Reverting this commit solved it.
>> >
>> > Is there something I can do to help investigate this?
>>
>> I assume you bisected all boot loader changes and it fails across this
>> commit? If not, that's the first step.
>>
>> If so, perhaps the place to start is with the dump?
>
> The dump is a good place to start, but it would also be useful to know
>
> 1) Which stage dies (e.g. can you get into the gptboot/boot2 prompt meaning
>    it it is probably btxldr.S dying trying to parse a.out header from
>    /boot/loader vs are you dying before that point meaning it is in boot1.S
>    or gptldr.S)?

Yes. This is absolutely critical. Until we know what dies, what the
trace backs are, what options were in effect and how the binaries were
broken there's little more that I can do because it works for me
everywhere I've tried it.

> 2) Once we know which stage, it would be good to compare the a.out headers
>    and possibly the contents of the relevant binaries.  The aforementioned
>    .S files all parse the a.out header in assembly as well as the BTX
>    header (they assume that BTX itself is present in the bits loaded from
>    disk immediately followed by the binary header).  That code isn't very
>    flexible and it doesn't seem far fetched for this change to break it.

I just wonder why it works on the amd64 servers and laptops, the i386
laptops and in qemu for me,  but fails for the OP. If it broke a.out,
I contend it would break for everybody since a.out headers are 'hit
dinosaur over the head' level of complexity and subtly.  While I don't
doubt there's a problem, I suspect it is very specific to a particular
set of laptops that were on the edge before and this kicks us over the
edge just enough to stomp on some area that was protected before.

Warner