Re: [PATCH, gdbsim] Avoid silly crash when no binary is loaded

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: Text/Plain, Size: 3848 bytes --]

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 reading 
the code and a bit of the mailing list.  i started hacking around ~Jan 2010, 
so i have no historical background which sometimes would be useful.  without 
any real documents or design info, i can only at best infer.  at least the 
files in common/ tend to be decently documented, so if you read the various 
headers enough, you can start to piece it together.  but maybe i'll hit you up 
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 ?
> 
> 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.
> 
> 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 Blackfin 
architecture, there is certainly overlap.  but i find their ultimate goals to 
be a bit at odds (or at least, how i perceive things).  personally, i find the 
level of tracing & gdb integration in the GNU/sim to be a lot better and 
stable than QEMU (just a mini example, but if you connect to QEMU's gdb 
backend, the SOB will eat a cpu because it sets the socket to nonblocking and 
then does read() in a loop).  the GNU/sim is also a much simpler design (QEMU 
really likes to segfault when something goes wrong) which lends itself to 
debugging.  certainly if i want speed or a "complete" Linux/user shim, i reach 
for QEMU.  but if i want to actually debug/trace some code, especially when it 
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 
rewrite all the lovely device models i've already put together for the 
GNU/sim.  so been trying to ponder some way of architecting things so i can 
copy & paste the core model files between the two.  hopefully the QEMU peeps 
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 
focusing with a GNU/sim focus at OSL a few years ago:
https://docs.google.com/document/d/1YE1ma7X-974-4GAcq1hg2Pom646yofRd6Fowol0BDC0/edit

i also did a presentation that broke down my experience between QEMU & the 
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 exactly 
large.  maybe SCALE or something.  i'm just lazy :/.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]