On Fri, Nov 20, 2015 at 04:41:21PM -0500, Andrew Jones wrote:
> On Fri, Nov 20, 2015 at 06:19:14PM +0000, Peter Maydell wrote:
> > On 19 November 2015 at 14:53, Andrew Jones <drjo...@redhat.com> wrote:
> > > +
> > > + if (is_a64(env)) {
> >
> > Are you really sure you want the core dump format to depend on
> > whether the CPU happens to be in 32-bit or 64-bit format at
> > the point in time we write it out? (Consider a 64-bit kernel
> > which happens to be running a 32-bit userspace binary.)
>
> I simply forgot to consider the case where a 64-bit kernel would
> run a 32-bit userspace binary. I'm actually quite sure we would
> want 64-bit in that case, as crash is the only tool we're able to
> generate dumps for at this time (gdb requires the 'paging' option
> of dump-guest-memory to work). Is there something in the env I can
> look at to determine that we have a 64-bit kernel? (Sorry for being
> lazy and just asking, rather than reading...)
Duh, I momentarily forgot about arm_el_is_aa64(env, 1). I see we unset
ARM_FEATURE_AARCH64 in aarch64_cpu_set_aarch64, so that should work
fine for our 32bit guests on 64bit hosts.
> > > + if (is_a64(env)) {
> > > + info->d_machine = EM_AARCH64;
> > > + info->d_class = ELFCLASS64;
> > > + if (cur_el == 0) {
> > > + be = (env->cp15.sctlr_el[1] & SCTLR_E0E) != 0;
> > > + } else {
> > > + be = (env->cp15.sctlr_el[cur_el] & SCTLR_EE) != 0;
> > > + }
> >
> > Again, are you sure you want the core dump format to depend on
> > whether we currently happen to be executing a BE userspace
> > process?
>
> We'll want to match the kernel. Hopefully we can determine it.
Here's a bigger, duh. I guess I just need to drop all the cur_el
stuff and stick to el==1.
I'll wait to hear back on the 'should we add ptrace.h to linux-headers',
and 'should we add floating point registers, even though crash won't
care' questions before sending a v2.
Thanks,
drew
