From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22712 invoked by alias); 20 Mar 2015 05:18:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 22702 invoked by uid 89); 20 Mar 2015 05:18:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 20 Mar 2015 05:18:11 +0000 Received: from vapier (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id EB235340C24; Fri, 20 Mar 2015 05:18:08 +0000 (UTC) Date: Fri, 20 Mar 2015 05:18:00 -0000 From: Mike Frysinger To: James Bowman Cc: "gdb-patches@sourceware.org" Subject: Re: [PATCH, FT32] gdb and sim support Message-ID: <20150320051809.GD11803@vapier> Mail-Followup-To: James Bowman , "gdb-patches@sourceware.org" References: <20150224045154.GE13523@vapier> <20150316082548.GC12926@vapier> <20150319185217.GC4128@vapier> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k4f25fnPtRuIRUb3" Content-Disposition: inline In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00618.txt.bz2 --k4f25fnPtRuIRUb3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4963 it mostly looks good. i made some fixes you should apply (see attached). there's some outstanding issues related to the memory handling. i think th= e=20 disconnect here is how the sim works. the core sim logic just processes the ISA and manages the core of the cpu -- it executes insns and handles the re= gs and sends requests to the memory. there are devices you can attach to the = main=20 memory bus (see common/dv-*.c for examples) so that when requests are made = to=20 addresses that a device is attached to, they automatically get routed to th= e=20 right code for you. this is where the model layers come into play. you declare specific cpu mo= dels=20 that have devices attached to known addresses. at runtime, you can select = from=20 the different models, and the sim will build that up. the power of the sim comes into play when you want to try out ideas for new= cpu=20 models. you can easily move device address attachments around, add more/le= ss=20 memory, and create models for hardware that doesn't yet exist. then run co= de in=20 that simulation and see how things work. > +#define RAM_BIAS 0x800000 /* Bias added to RAM addresses. */ what's with this ? if the code requests address 0, it should go to address= 0. > +/* Align EA according to its size DW. */ > +static uint32_t ft32_align (uint32_t dw, uint32_t ea) what's with this ? is this how the hardware works ? e.g. if the PC is set= to=20 0x101, it'll mask off the low bit ? or will it throw an exception ? same = for=20 if it reads/writes address 0x101. > +/* Read an item from memory address EA, sized DW. */ > +static uint32_t > +ft32_read_item (SIM_DESC sd, int dw, uint32_t ea) > +{ > + sim_cpu *cpu =3D STATE_CPU (sd, 0); > + uint8_t byte[4]; > + uint32_t r; > + > + ea =3D ft32_align (dw, ea); > + sim_core_read_buffer (sd, cpu, read_map, byte, ea, 1 << dw); > + r =3D byte[0]; > + if (1 <=3D dw) > + { > + r +=3D (byte[1] << 8); > + if (2 <=3D dw) > + { > + r +=3D byte[2] << 16; > + r +=3D byte[3] << 24; > + } > + } > + return r; > +} you should be able to use sim_core_read_aligned_{1,2,4} here instead of rea= ding=20 and unpacking the byte array yourself you should check the return value of the sim core read function > +/* Write item V to memory address EA, sized DW. */ > +static void > +ft32_write_item (SIM_DESC sd, int dw, uint32_t ea, uint32_t v) > +{ > + sim_cpu *cpu =3D STATE_CPU (sd, 0); > + uint8_t byte[4]; > + > + ea =3D ft32_align (dw, ea); > + > + byte[0] =3D v & 0xff; > + byte[1] =3D (v >> 8) & 0xff; > + byte[2] =3D (v >> 16) & 0xff; > + byte[3] =3D (v >> 24) & 0xff; > + sim_core_write_buffer (sd, cpu, write_map, byte, ea, 1 << dw); > +} this looks like assumes the memory is little endian. should it be using=20 sim_core_write_unaligned_{1,2,4} instead ? you should check the return value of the sim core write function > +static uint32_t cpu_mem_read (SIM_DESC sd, uint32_t dw, uint32_t ea) > +{ > + sim_cpu *cpu =3D STATE_CPU (sd, 0); > + uint32_t insnpc =3D cpu->state.pc; > + uint32_t r; > + uint8_t byte[4]; > + > + ea &=3D 0x1ffff; > + if ((ea & ~0xffff)) > + { > + switch (ea) > + { > + case 0x1fff4: > + /* Read the simulator cycle timer. */ > + return cpu->state.cycles / 100; > + default: > + sim_io_eprintf (sd, > + "Illegal IO read address %08x, pc %#x\n", > + ea, > + insnpc); > + ILLEGAL (); > + } > + } > + return ft32_read_item (sd, dw, RAM_BIAS + ea); > +} > + > +static void cpu_mem_write (SIM_DESC sd, uint32_t dw, uint32_t ea, uint32= _t d) > +{ > + sim_cpu *cpu =3D STATE_CPU (sd, 0); > + ea &=3D 0x1ffff; > + if (ea & 0x10000) > + { > + switch (ea) > + { > + case 0x10000: > + putchar (d & 0xff); > + break; > + case 0x1fc80: > + cpu->state.pm_unlock =3D (d =3D=3D 0x1337f7d1); > + break; > + case 0x1fc84: > + cpu->state.pm_addr =3D d; > + break; > + case 0x1fc88: > + ft32_write_item (sd, dw, cpu->state.pm_addr, d); > + break; > + case 0x10024: > + break; > + case 0x1fffc: > + /* Normal exit. */ > + sim_engine_halt (sd, cpu, NULL, cpu->state.pc, sim_exited, cpu->state= .regs[0]); > + break; > + case 0x1fff8: > + case 0x19470: > + sim_io_printf (sd, "Debug write %08x\n", d); > + break; > + default: > + sim_io_eprintf (sd, "Unknown IO write %08x to to %08x\n", d, ea); > + } > + } > + else > + ft32_write_item (sd, dw, RAM_BIAS + ea, d); > +} what's with these addresses ? are you trying to simulate attached hardware= =20 devices ? > + /* CPU specific initialization. */ > + for (i =3D 0; i < MAX_NR_PROCESSORS; ++i) > + { > + SIM_CPU *cpu =3D STATE_CPU (sd, i); > + > + CPU_REG_FETCH (cpu) =3D ft32_reg_fetch; > + CPU_REG_STORE (cpu) =3D ft32_reg_store; > + } still should implement the CPU_PC_FETCH/etc... stuff i suggested earlier. that way the builtin profile functions will work automatically. $ ./run -p -v ./some-elf -mike --k4f25fnPtRuIRUb3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVC62RAAoJEEFjO5/oN/WBs9UQAJRs/i851rh5/YZ2lB0Xm6D6 o528RvqasrMG+56fiGkk6ocCl5o/w64f9E+UplLqsE6vrtp/SN5RD93P7ttQX3sJ ITGGdzkXMzpGCUDUAXzMCA2CRTdrKJZoHgFTbpd4wYsMRpAk5uYbvISIFaBzpGwx DmWHqvoQVpCV692tVV1+vX4MkzBxCChh+HBFWJfRjKDsJqnqi/G52U0l97nXMyis TZKhw0Eb/O5Zb2fPl912WcBGEITUwu3C6wgpBLyhnVIZ/Yv6Etq/N1ssNjZE1QZp 47a57B88dSwxriaCxxIdB+GM1ht1Gtsd+ZCncpDXmPiI4C0x7QOgF3BgvjhIzLnT bfQEKuhZSCdxw1JcIybezJZlSLCniIBUbChb9zYS9HDDrt+cf6dR0kEUZqImAPsP 2VRGoFeuw843CZrZvHJ8a64uf3VUenh1XdC5SPwKzMACbugA60BVeK0TXGSTdohl yWW/nOnqGupMEQO4IUTvqkP10R+Lxf/y0X4+UMTStlxYY2HIHIc+l4Fn6P0CVmR/ vCcgSJtq4IroN6c9hTaecAnbC9z9nEu0OVlaVdTIeG6hJfPZZ9i+N/cBEb5x1ZWD enrUIi+poJOTe8kHTNfdyaO7X0ilSQYxoKOwljmdS1DrqiNVEDC717M2zS1fS/IS 9Qtk2E9oVL7+u4nvpxB8 =S/FA -----END PGP SIGNATURE----- --k4f25fnPtRuIRUb3--