From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21445 invoked by alias); 20 Jun 2013 20:45:12 -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 21403 invoked by uid 89); 20 Jun 2013 20:45:12 -0000 X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,TW_QE autolearn=ham version=3.3.1 Received: from elasmtp-kukur.atl.sa.earthlink.net (HELO elasmtp-kukur.atl.sa.earthlink.net) (209.86.89.65) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 20 Jun 2013 20:45:11 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UpljA-0002Qh-Vh for gdb-patches@sourceware.org; Thu, 20 Jun 2013 16:45:09 -0400 Message-ID: <51C369CF.8070102@earthlink.net> Date: Thu, 20 Jun 2013 21:33:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [PATCH, gdbsim] Avoid silly crash when no binary is loaded References: <51C0C7E3.1030603@codesourcery.com> <51C193AE.7010608@redhat.com> <51C19FF0.8000005@codesourcery.com> <201306201350.31839.vapier@gentoo.org> In-Reply-To: <201306201350.31839.vapier@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940083e4d4c6e6280cb063444639878784b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-SW-Source: 2013-06/txt/msg00571.txt.bz2 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