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 ...

[John Baldwin]

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)?

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.

-- 
John Baldwin