From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27042 invoked by alias); 20 Jun 2013 21:33:34 -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 27004 invoked by uid 89); 20 Jun 2013 21:33:30 -0000 X-Spam-SWARE-Status: No, score=-9.6 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS,TW_QE autolearn=ham version=3.3.1 Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 20 Jun 2013 21:33:29 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 54E5B33E61B; Thu, 20 Jun 2013 21:33:27 +0000 (UTC) From: Mike Frysinger To: gdb-patches@sourceware.org Subject: Re: [PATCH, gdbsim] Avoid silly crash when no binary is loaded Date: Thu, 20 Jun 2013 22:00:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.8.3; KDE/4.6.5; x86_64; ; ) Cc: Stan Shebs References: <51C0C7E3.1030603@codesourcery.com> <201306201350.31839.vapier@gentoo.org> <51C369CF.8070102@earthlink.net> In-Reply-To: <51C369CF.8070102@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4338643.W4LYJDpeQx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201306201733.31043.vapier@gentoo.org> X-Virus-Found: No X-SW-Source: 2013-06/txt/msg00572.txt.bz2 --nextPart4338643.W4LYJDpeQx Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 3872 On Thursday 20 June 2013 16:45:03 Stan Shebs wrote: > The "exec creates the simulation" model is the original one, introduced > by Steve Chamberlain in 1992 or so. It actually predates my time at > Cygnus, so I don't have any direct knowledge of the decision process, > but I remember having to consider how to keep sims from pre-allocating a > too-large address space for the hosts of the time; using the exec to > size memory was a convenient way to ensure enough space was allocated, > and avoided having to come up with a fancy allocate-on-demand scheme > (which could have been a problem for simulation speed, seems quaint now > but was also a concern at the time). you've shown your hand! my knowledge of the sim is really only from readin= g=20 the code and a bit of the mailing list. i started hacking around ~Jan 2010= ,=20 so i have no historical background which sometimes would be useful. withou= t=20 any real documents or design info, i can only at best infer. at least the= =20 files in common/ tend to be decently documented, so if you read the various= =20 headers enough, you can start to piece it together. but maybe i'll hit you= up=20 with random questions :). > > now, when you talk about the other environments (like the virtual or > > user), what you want makes a bit more sense as there's not a whole lot > > you could reasonably do. but i don't think we should head in a > > direction that moves even farther away from what i desire above for the > > operating environment. maybe there's some middle ground ? >=20 > At the risk of stealth trolling via Nth reply to a patch :-) , I'd like > to understand why we're continuing to maintain our own sims when qemu > exists. Qemu has infrastructure for all the device/board simulation, it > supports a variety of architectures, and it gets a lot of use, including > for GDB testing. >=20 > I'm not saying we should start deleting code en masse, but perhaps we > can articulate a rule for relying on qemu vs not, and then that informs > us where to expend effort in our sources. a fair point. having ported both the GNU/sim and QEMU to support the Black= fin=20 architecture, there is certainly overlap. but i find their ultimate goals = to=20 be a bit at odds (or at least, how i perceive things). personally, i find = the=20 level of tracing & gdb integration in the GNU/sim to be a lot better and=20 stable than QEMU (just a mini example, but if you connect to QEMU's gdb=20 backend, the SOB will eat a cpu because it sets the socket to nonblocking a= nd=20 then does read() in a loop). the GNU/sim is also a much simpler design (QE= MU=20 really likes to segfault when something goes wrong) which lends itself to=20 debugging. certainly if i want speed or a "complete" Linux/user shim, i re= ach=20 for QEMU. but if i want to actually debug/trace some code, especially when= it=20 comes to something like u-boot or kernel testing, i reach for the GNU/sim. as i've been trying to bring up the QEMU Blackfin/system port, i don't want= to=20 rewrite all the lovely device models i've already put together for the=20 GNU/sim. so been trying to ponder some way of architecting things so i can= =20 copy & paste the core model files between the two. hopefully the QEMU peep= s=20 aren't as angry when it comes to HAL shims like the Linux kernel community. fwiw, i wrote a paper with a friend of mine on the topic of simulation=20 focusing with a GNU/sim focus at OSL a few years ago: https://docs.google.com/document/d/1YE1ma7X-974-4GAcq1hg2Pom646yofRd6Fowol0= BDC0/edit i also did a presentation that broke down my experience between QEMU & the= =20 GNU/sim and some of the tradeoffs at LSM: http://wh0rd.org/~vapier/lsm-2012-sim.pdf i think i'll try and give those presentations again as OSL/LSM weren't exac= tly=20 large. maybe SCALE or something. i'm just lazy :/. -mike --nextPart4338643.W4LYJDpeQx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJRw3UqAAoJEEFjO5/oN/WB+uUP/3Eq8sAx9wBYxsY0wBxhKlEZ 0IH3xuHUopuzM4kt2tIZjjNcRTR+Rw1uJiJzWEMOWHkfahA4FB2FlmYp1s10J81f u5xauamRjFxEU/2AV6a7UJJkv9ff3+DKbKmXeEfgh5laI3YRR0YmFqUvCC8Impnr HVhtdZAK0OQxryN2oHZrzsrDne05jdb3X1IvpoDdNwLv0TV5TuokOjt5l/WsP35A DLXF9Oevkl82OPgyk//9HPidMGvFyOrLwuO48Kt9fKbW4zsK4ejGMAA/h2EYyKXQ j1m85ZHv2ZSqPWWsKZwqd5dx7E17v27XF2pI60Ll0Af6xDlNgNxqxXU7+Y9U0oLJ B0m/f8L41qdRunu/SFBgOMBHTw1IJHJcQOVEkEqipNov3rmuB5xcilp95kzEs3Uc e8P8EfOVN0sCIlHgT2LseaQFfBDf3TP7zCeAfS6mgxtAE/zE2O4dfVcwmZSYbBy9 YSe/3UvsBXDqY+VgNPhmZLHyJZH5/1GeKeoUxpPsz/GNDmmwN68GlQemm24Jwd5S uyg6xFKe8izGKdlMvY5mIVEBEylt8IK9kRrxz8uRby9NYYZ5GLiNW28Ih51dkKJQ tOG7WSK2uOHwCAU0kgHtwPU/OTK1tDn/C0IM5Vp054CwQREEK44yfCo9TSZJqloy l2LJ7zyaZJz9c4pAZxTj =sJ3I -----END PGP SIGNATURE----- --nextPart4338643.W4LYJDpeQx--