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

[Stan Shebs <stanshebs at earthlink dot net>]

On 6/20/13 10:50 AM, Mike Frysinger wrote:
> On Wednesday 19 June 2013 08:11:28 Luis Machado wrote:
>> On 06/19/2013 08:19 AM, Pedro Alves wrote:
>>> SIM_RC
>>> sim_create_inferior (SIM_DESC sd, struct bfd *abfd,
>>> 		     char **argv, char **env)
>>> {
>>>    SIM_CPU *cpu = STATE_CPU (sd, 0);
>>>    SIM_ADDR addr;
>>>    
>>>    /* Set the PC.  */
>>>    if (abfd != NULL)
>>>      addr = bfd_get_start_address (abfd);
>>>    else
>>>      addr = 0;
>>>    sim_pc_set (cpu, addr);
>>
>> Is there a good reason why bfin would allow things to proceed without
>> any image? It doesn't even run past that point really.
> 
> because it'd segfault otherwise ;)
> $ ./gdb/gdb -q
> (gdb) target sim
> Connected to the simulator.
> (gdb) run
> Starting program:  
> warning: No executable file specified.
> warning: No program loaded.
> Segmentation fault (core dumped)
> 
>> If running, and by that i mean issuing run/start/continue/step commands,
>> the simulators with no image is a valid use case, then sounds like
>> steering the arm simulator to just do more or less what the other
>> simulators do is the right thing.
> 
> well, there's a bit more nuance than that.  consider the operating environment 
> (literally, --environment operating).  when you connect to that, it's like you 
> took jtag and connected it to a cpu fresh out of reset.  sure, there's no 
> "program" loaded in its memory, but there's still plenty you can do to the 
> device like poke memory and see how it reacts -- whether it be external SDRAM, 
> or a parallel flash, or on-chip L1/L2, or memory mapped registers for the 
> peripherals, or an async memory bus, or an on-chip boot/ROM (which has both 
> code & data).  maybe i'm an odd ball, but i find this scenario great for both 
> testing, development (like writing new sim device models), and one-off checks.  
> the fact that i need to compile & link a dummy program just to load it into 
> the sim so i can start poking around is obnoxious.  similarly, when i have 
> just a .bin of raw code/data (e.g. `objcopy -O binary foo.elf foo.bin` which 
> is common in the embedded world), how am i going to get that into the 
> simulator ?  when i'm connected to jtag, i could use "load" & friends to copy 
> it to memory, set the pc, and let it run.  with the sim, i need to create a 
> dummy .s that does .incbin "foo.bin" and compile+link that.

I agree that having this sort of environment is useful.

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).

> 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.

Stan
stan@codesourcery.com