On 6 December 2016 at 15:51, Julian Brown wrote:
> On Tue, 6 Dec 2016 15:44:07 +
> Peter Maydell wrote:
>
>> On 6 December 2016 at 15:11, Julian Brown
>> wrote:
>> > On Thu, 3 Nov 2016 22:23:09 +
>> > Peter Maydell wrote:
>> >
>> >> Strong 'no' for the approach of having different CPU
>
On Tue, 6 Dec 2016 15:44:07 +
Peter Maydell wrote:
> On 6 December 2016 at 15:11, Julian Brown
> wrote:
> > On Thu, 3 Nov 2016 22:23:09 +
> > Peter Maydell wrote:
> >
> >> Strong 'no' for the approach of having different CPU
> >> names, I'm afraid. What you want is to have a CPU
> >>
On 6 December 2016 at 15:11, Julian Brown wrote:
> On Thu, 3 Nov 2016 22:23:09 +
> Peter Maydell wrote:
>
>> Strong 'no' for the approach of having different CPU
>> names, I'm afraid. What you want is to have a CPU
>> property which works like the hardware CPU's CFGEND
>> signal to set the re
On Thu, 3 Nov 2016 22:23:09 +
Peter Maydell wrote:
> Strong 'no' for the approach of having different CPU
> names, I'm afraid. What you want is to have a CPU
> property which works like the hardware CPU's CFGEND
> signal to set the reset value of the SCTLR.EE bit. Then
> a board can use that
On 04/11/2016 11:25, Julian Brown wrote:
> > The change to arm_cpu_memory_rw_debug for BE32 is also interesting.
> > gdb documentation says
> >
> > The stub need not use any particular size or alignment when
> > gathering data from memory for the response; even if ADDR is
> > word
On Fri, 4 Nov 2016 09:48:06 +0100
Paolo Bonzini wrote:
> On 04/11/2016 00:34, Julian Brown wrote:
> >
> > So (IIRC!) the gdbstub needs to interpret some of these read/write
> > values on the host, i.e. in host byte ordering. "Traditionally", the
> > ldl_p and stl_p (etc.) macros would byteswap d
On 03/11/2016 23:23, Peter Maydell wrote:
> (For the rest of the series: you've missed the 2.8
> freeze, and I'm on holiday for most of November, so
> it may be a while before I can get to it; hopefully
> somebody else will step up and have a look at it.)
2/4/5 are relatively obvious bugfixes (i
On 04/11/2016 00:34, Julian Brown wrote:
>
> So (IIRC!) the gdbstub needs to interpret some of these read/write
> values on the host, i.e. in host byte ordering. "Traditionally", the
> ldl_p and stl_p (etc.) macros would byteswap depending on the
> TARGET_WORDS_BIGENDIAN setting -- that's how co
On Thu, 3 Nov 2016 22:23:09 +
Peter Maydell wrote:
> On 3 November 2016 at 17:30, Julian Brown
> wrote:
> > This patch improves support for semihosting and debugging with the
> > in-built gdbstub for ARM system-mode emulation in big-endian mode
> > (either BE8 or BE32), after the fairly rece
On 3 November 2016 at 17:30, Julian Brown wrote:
> This patch improves support for semihosting and debugging with the
> in-built gdbstub for ARM system-mode emulation in big-endian mode (either
> BE8 or BE32), after the fairly recent changes to allow a single QEMU
> binary to deal with each of LE,
This patch improves support for semihosting and debugging with the
in-built gdbstub for ARM system-mode emulation in big-endian mode (either
BE8 or BE32), after the fairly recent changes to allow a single QEMU
binary to deal with each of LE, BE8 and BE32 modes in one. It's only
currently good for l
11 matches
Mail list logo
