Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
Paul Brook wrote: This is similar to why I dislike qemu automagically guessing settings. If you force everything to be explicitly specified (or use fixed defaults) then there's no margin for error. If behaviour depends on external factors then you can guarantee the person stuck between you (the "expert") and the misbehaving application will have no clue how to determine or control those external factors. Come on, if the concern is being able to determine the users environment, there are very well understood ways to handle this. Just have QEMU log all of the configuration parameters to some log file upon startup like so many other applications do. If people don't like using environmental variables, I can accept that. Let's not pretend though that the reason is that we're protecting the end users :-) Regards, Anthony Liguori Paul
Re: [Qemu-devel] What does code_copy_enabled do?
In message: <[EMAIL PROTECTED]> Paul Brook <[EMAIL PROTECTED]> writes: : > > Any news on the possible cvs->svn migration? : > : > To be perfectly honest, IMO there is little point moving an existing : > project from CVS to SVN. : : I disagree. CVS has several fairly fundamental flaws (no global revision IDs, : unable to move files, and more subtle problems with branches/tags). : SVN fixes these, and in most cases works as a direct drop-in replacement for : CVS. FreeBSD is moving from CVS to SVN for these reasons. : While I can see that distributed revision control systems do enable some : interesting possibilities, there's certainly no clear winner. All of them : seem to have have fairly serious issues with either usability, portability, : scalability, and/or require learning a whole new workflow. I'm sure : advocates of each system will claim that their system is the "best", but I : remain unconvinced. Well, svn now has svn to hg and svn to git gateways, so really it caters to all comers... Warner
Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
> I think Paul Brook was concerned about a situation where a user > reports a problem saying FOO is not working when running "qemu -hda ..." > and suddenly the number of things that may have triggered the bug has > grown by the size of the environment. Even if you manage to tell the > user to pastebin the environment, it may have changed by then. I'm > pretty sure Paul knows how to list the env variables :) Indeed. I see many, many users complain that qemu dies because of SDL errors. Almost without fail this is because they're running qemu in a different environment (e.g. under su as root), so are using an environment that can't connect to their X server. Running "set | grep QEMU" is fine, except that it has to be done in the same environment as qemu runs in. You'd be surprised how many users are incapable of doing what seems to be a straightforward task. This is similar to why I dislike qemu automagically guessing settings. If you force everything to be explicitly specified (or use fixed defaults) then there's no margin for error. If behaviour depends on external factors then you can guarantee the person stuck between you (the "expert") and the misbehaving application will have no clue how to determine or control those external factors. Paul
Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
On Monday 11 February 2008 15:28:17 Johannes Schindelin wrote: > Hi, > > On Mon, 11 Feb 2008, Rob Landley wrote: > > I've been using git://git.kernel.dk/data/git/qemu.git although I > > personally prefer mercurial. (It's easier to learn and to use, you get > > the web viewer for free, etc.) > > I really grow tired of people perpetuating how "easy" Mercurial is, > without substantiating it. And the macintosh has a nicer desktop than Gnome, too. :P > Granted, git _used_ to be more difficult, but > now? No, really. I wrote "http://kernel.org/doc/local/git-quick.html";, so I'm not speakign entirely from ignorance when I say that Mercurial is way the heck easier to set up and to use. In mercurial, the human readable web repository viewer and the server you pull from are the same thing (and part of the same package). They're different packages in git, set up differently, and live at arbitrarily different URLs such that knowing where to pull from doesn't let you know where a web repository viewer is (or even if there _is_ one, since it's a lot of extra work to set up in git but comes free in mercurial). There's also no mercurial equivalent to the "git update-server-info" comand because it doesn't need one, and if you're behind a firewall that only allows http access you can pull from mercurial but not from git. Also, since the mercurial repository uses apache as its server just use https:// and you get encryption for free, while git has to reimplement all that. You never have to "pack" or "git gc" a mercurial repository. You don't have to install a seperate documentation package in order for "hg help command" to work. The mercurial command syntax doesn't vary wildly depending on which version you have installed, in git it's totally different before 1.5.0 and after... Shall I go on? I dunno an archive for the users at kernel.org mailing list but the vast majority of the traffic is "strange, subtle, and painful things that can go wrong with git". (It's not a high traffic list, but still.) That said, it's the source control system the kernel guys use, and it _is_ the same basic concepts as any other distributed SCM (with a horrible user interface). I don't _object_ to using it, I just don't prefer it. > The biggest obstacle to using a distributed VCS is that many people do not > grasp, and indeed do not even care about, the concept of a distributed > VCS. For me, going from svn to hg was less pain than going from cvs to svn had been. I like mercurial because going "hg log -v", or "hg update -r 12345" is an entirely local operation that doesn't have to go out on the network. I can tell mercurial to spit out a tarball of any arbitrary historical version (or just put it in a directory directly), again without waiting for access to a server and hoping it's up. You get darn spoiled by that, really quick. (And this doesn't even count the maintainer-only stuff like being able to do checkins on plane flights or long car trips. And said checkin taking a fraction of a second to commit, and _never_ having a conflict during the commit stage.) You don't have to worry about new concepts until you want to use branching and merging, which I really don't much. > That's perfectly fine with me, if you don't want to use a distributed > tool, I do not want to force it down your throat. FWIW I am happily using > git on top of CVS, thankyouverymuch. *shrug* Now that the git mirror I use is updating again, I admit my motivation on this topic's dried up a bit. :) > Ciao, > Dscho Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Re: [Qemu-devel] What does code_copy_enabled do?
> > Any news on the possible cvs->svn migration? > > To be perfectly honest, IMO there is little point moving an existing > project from CVS to SVN. I disagree. CVS has several fairly fundamental flaws (no global revision IDs, unable to move files, and more subtle problems with branches/tags). SVN fixes these, and in most cases works as a direct drop-in replacement for CVS. While I can see that distributed revision control systems do enable some interesting possibilities, there's certainly no clear winner. All of them seem to have have fairly serious issues with either usability, portability, scalability, and/or require learning a whole new workflow. I'm sure advocates of each system will claim that their system is the "best", but I remain unconvinced. SVN may not have the bells and whistles of some of the more exotic systems. However it is is well tested proven technology, and IMO universally better than CVS. Paul
Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
On 12/02/2008, Rob Landley <[EMAIL PROTECTED]> wrote: > On Saturday 19 January 2008 15:10:09 Paul Brook wrote: > > It's also extremely hard to determine what environment a user is running. > > Type "set" with no arguments. (I admit bash 3.x throws insane amounts of crap > into this by default, but any program that's exposed to the FSF for an > extended period of time bloats beyond recognition.) I think Paul Brook was concerned about a situation where a user reports a problem saying X is not working when running "qemu -hda ..." and suddenly the number of things that may have triggered the bug has grown by the size of the environment. Even if you manage to tell the user to pastebin the environment, it may have changed by then. I'm pretty sure Paul knows how to list the env variables :) I personally can accept not knowing what environment the user is running though. You'll never be able to reproduce 100% of user-reported bugs (and usually you won't even try), and any new way of configuring qemu that you introduce (say, config files) will have the same problem. -- Please do not print this email unless absolutely necessary. Spread environmental awareness.
Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
On Tuesday 12 February 2008, Rob Landley wrote: > On Saturday 19 January 2008 15:10:09 Paul Brook wrote: > > > In the absence of a global configuration file, a reasonably sane way to > > > support this configuration system wide is to use an environmental > > > variable. QEMU already uses a number of global variables for > > > configuring audio options. > > > > I'd really prefer we didn't do this, and preferably obsoleted/removed the > > existing environment variables. IMHO using environment variables is a > > really bad idea and should be avoided wherever possible. > > > > Environment variables are about the worst user interface I can think of. > > For a start they're a global resource, which is limited on some systems. > > On Windows, you mean? Windows is a particularly bad example, yes. > > It's also extremely hard to determine what environment a user is running. > > Type "set" with no arguments. (I admit bash 3.x throws insane amounts of > crap into this by default, but any program that's exposed to the FSF for an > extended period of time bloats beyond recognition.) > > The sane way to do this is prefix all the environment variables QEMU uses > with QEMU_ so you can go > > set | grep QEMU > > And see just what you're interested in. > > Would that make this approach more palatable? No. Paul
Re: [PATCH][Qemu-devel] Single stepping for PPC broken!
On Thursday 10 January 2008 07:57:50 Marius Groeger wrote: > The attached patch fixes the problem, but I have to admit I can't tell > for sure if this doesn't break other things (such as qemu's built-in > GDB server). Could some QEMU ppc expert please comment on this? Looks fine to me, but I don't see it in the git mirror I follow... Did anybody notice this patch? Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Re: [Qemu-devel] [PATCH] Allow default network type to be determined from an environmental variable
On Saturday 19 January 2008 15:10:09 Paul Brook wrote: > > In the absence of a global configuration file, a reasonably sane way to > > support this configuration system wide is to use an environmental > > variable. QEMU already uses a number of global variables for > > configuring audio options. > > I'd really prefer we didn't do this, and preferably obsoleted/removed the > existing environment variables. IMHO using environment variables is a > really bad idea and should be avoided wherever possible. > > Environment variables are about the worst user interface I can think of. > For a start they're a global resource, which is limited on some systems. On Windows, you mean? They're a per-process resource on Linux. Inherited from the parent process, sure, but you inherit _copies_ of them, and changes you make to those copies don't propagate to parent processes. (A given process's environment variables aren't even necessarily passed on to its child processes. You supply the envionment variables to the syscall and wrappers like execle() let you specify. The "env" command exists to do this for you.) Essentially the environment variables passed into a process are a second set of command line arguments (literally: argument 3 to main() is your list of environment variables, an array of pointers to "name=value" strings, with a null pointer terminating the array. Generally your setup code copies this pointer to _environ but you can grab it manually if you like.) There's no limit on the size here any more than there is on command line arguments. (Your _shell_ may limit command line arguments, but you can pipe stuff to xargs to get around that.) > It's also extremely hard to determine what environment a user is running. Type "set" with no arguments. (I admit bash 3.x throws insane amounts of crap into this by default, but any program that's exposed to the FSF for an extended period of time bloats beyond recognition.) The sane way to do this is prefix all the environment variables QEMU uses with QEMU_ so you can go set | grep QEMU And see just what you're interested in. Would that make this approach more palatable? Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Re: [Qemu-devel] [PATCH] SCSI support for vmdk images
On Sat, Feb 09, 2008 at 01:40:33AM -0600, Rob Landley wrote: >> I just noticed this patch, I've had lying around for a while, but >> forgot to send here. > What does this do that the patch back in september didn't? Sorry, I forgot to include that bit. The patch from September made qemu-img able to create version 6 vmware images (in addition to version 4). This new one make qemu-img able to create scsi vmware images. -- Soren Hansen Virtualisation specialist Ubuntu Server Team http://www.ubuntu.com/ signature.asc Description: Digital signature
Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
Hi, On Mon, 11 Feb 2008, Rob Landley wrote: > I've been using git://git.kernel.dk/data/git/qemu.git although I > personally prefer mercurial. (It's easier to learn and to use, you get > the web viewer for free, etc.) I really grow tired of people perpetuating how "easy" Mercurial is, without substantiating it. Granted, git _used_ to be more difficult, but now? No, really. The biggest obstacle to using a distributed VCS is that many people do not grasp, and indeed do not even care about, the concept of a distributed VCS. That's perfectly fine with me, if you don't want to use a distributed tool, I do not want to force it down your throat. FWIW I am happily using git on top of CVS, thankyouverymuch. Ciao, Dscho
Re: [Qemu-devel] What does code_copy_enabled do?
On Feb 11, 2008 10:38 PM, Johannes Schindelin <[EMAIL PROTECTED]> wrote: > Hi, > > On Mon, 11 Feb 2008, Felipe Contreras wrote: > > > The advantage of using SVN is that most drcs play along with it quite > > decently. Something that doesn't happen with CVS. > > So you're saying in order to use a DVCS you would need to switch to a > CVCS? I'm saying * > CVS. Even SVN would be fine. BTW, I found the issue, it's on "linux-user/mmap.c" :) -- Felipe Contreras
Re: [Qemu-devel] What does code_copy_enabled do?
On Monday 11 February 2008 14:38:42 Johannes Schindelin wrote: > Hi, > > On Mon, 11 Feb 2008, Felipe Contreras wrote: > > The advantage of using SVN is that most drcs play along with it quite > > decently. Something that doesn't happen with CVS. > > So you're saying in order to use a DVCS you would need to switch to a > CVCS? No, you need to switch _off_ of CVS. CVS hasn't got the concept of "changesets". You can treat a real CVCS as a DVCS that' s never branched, just a linear series of changesets with no merge nodes. But CVS _isn't_ a real CVCS. It's not a series of changesets, it's a bunch of separately tracked files. You know how a single patch can touch a dozen different files? CVS doesn't understand that. Its dumber than the "patch" program. In CVS, every single file stands alone, its history unrelated to any of the others. Out of sheer self-preservation, most CVS users check in changes to lots of different files at once, with identical comments, so you can go back later and match changes up by timestamp and check that the comments match. But this is just a heuristic, dependent on the behavior of the users, and it only sort of works at the best of times because unless your CVS server is infinitely fast, the timestamps won't be _identical_ but just _close_. How close is close enough? Don't go there. (I tried to write such a script once. It hurt.) But having to do data mining in order to detect changesets is an evil specialized black art, it breaks easily, and generally you want to convert up to at least something that understands changesets and NEVER LOOK BACK. > Puzzled, > Dscho Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
[Qemu-devel] Something fishy on linux-user/mmap.c
Hi, There's something wrong with the commit edbcc0b2eb1d4caee5f293e5c79f81023f3394e2. I'm using qemu-0.9.1 + 09_arm_eabitls.patch[1], for CodeSourcery's arm-2006q3 (otherwise it can't run on Fedora 8) The following Makefile fails when trying to execute "simple", a recently built binary: bar: echo bar ./simple foo: $(MAKE) bar I get "make[1]: *** [bar] Segmentation fault", but if I remove "echo bar", it works. If I revert that commit for mmap.c, it works fine. Any ideas? [1] http://www.mail-archive.com/qemu-devel@nongnu.org/msg14659.html -- Felipe Contreras
Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?
On Saturday 09 February 2008 10:49:49 Johannes Schindelin wrote: > Hi, > > On Sat, 9 Feb 2008, Felipe Contreras wrote: > > Right now I can't use qemu because a bug introduced in the last months > > and with git-bisect I probably would be able to fix it myself. > > Just clone git://repo.or.cz/qemu.git, then. I've been using git://git.kernel.dk/data/git/qemu.git although I personally prefer mercurial. (It's easier to learn and to use, you get the web viewer for free, etc.) The thing is, git and mercurial are roughly equivalent, they're both distributed source control systems and you can losslessly convert from one to the other and back again, because they have all the same metadata. (See http://kernel.org/hg/linux-2.6 as an example of a mercurial mirror of a git repository.) But the difference between centralized source control and distributed source control is huge. The distributed ones store more information. This means you can convert losslessly convert from svn->hg, but if you convert from hg->svn you lose information. (So if you convert from hg->svn and then back from svn->hg, you have a different mercurial repository, and pulling from the original would be a bad idea because it would think it had lots of duplicate changes.) And of course CVS isn't even a full fledged centralized repository, it's an ancient holdover from the 1980's that doesn't even have the concept of "changesets". (In cvs, changes are tracked in individual files. Changes that touch multiple files at the same time have to be collated after the fact by comparing timestamps and hoping the descriptions match up. This is a brittle heuristic at best; CVS hasn't got this _concept_. Doing a binary search for the change that introduced a bug is amazingly painful with CVS, and even proposing tracking renames violates the design assumptions. Even patch knows how to touch more than one file at a time; CVS does not.) It is possible to use a distributed source control system as if it were a centralized source control system. Just accept all changes as patches, never pulling directly from any other trees. And thus you can hold off on learning new distributed source control concepts indefinitely. > Hth, > Dscho Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
Re: [Qemu-devel] What does code_copy_enabled do?
Hi, On Mon, 11 Feb 2008, Felipe Contreras wrote: > The advantage of using SVN is that most drcs play along with it quite > decently. Something that doesn't happen with CVS. So you're saying in order to use a DVCS you would need to switch to a CVCS? Puzzled, Dscho
[Qemu-devel] qemu/hw sun4m.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 08/02/11 20:01:36 Modified files: hw : sun4m.c Log message: Fix SS-20 auxio addresses CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemu&r1=1.83&r2=1.84
Re: [Qemu-devel] What does code_copy_enabled do?
On Feb 11, 2008 5:52 PM, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> > Any news on the possible cvs->svn migration?
>
> To be perfectly honest, IMO there is little point moving an existing
> project from CVS to SVN. SVN has better support for renames, and a
> few other advantages, but branching is still pretty catastrophic.
>
> Any of the currently popular drcs's would be a big improvement. In
> particular it would make it much easier to do development on changes
> that don't want to go in CVS mainline for any reason.
The advantage of using SVN is that most drcs play along with it quite
decently. Something that doesn't happen with CVS.
--
Felipe Contreras
[Qemu-devel] qemu/target-sparc cpu.h helper.c op_helper.c tr...
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 08/02/11 18:27:33 Modified files: target-sparc : cpu.h helper.c op_helper.c translate.c Log message: Sparc32 MMU register fixes (Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/cpu.h?cvsroot=qemu&r1=1.61&r2=1.62 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/helper.c?cvsroot=qemu&r1=1.33&r2=1.34 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemu&r1=1.65&r2=1.66 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemu&r1=1.86&r2=1.87
Re: [Qemu-devel] What does code_copy_enabled do?
Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> Now, that is funny. You quote me, and you quote Rob, but culled both of
> us from the Cc list.
How strange. I definitely didn't mean to do that, sorry.
...tests...
This is the fault of the Reply-To munging.
Ian.
Re: [Qemu-devel] What does code_copy_enabled do?
Hi,
On Mon, 11 Feb 2008, Ian Jackson wrote:
> Johannes Schindelin writes ("Re: Git/SVN/CVS? was Re: [Qemu-devel] What does
> code_copy_enabled do?"):
> > Just clone git://repo.or.cz/qemu.git, then.
>
> Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> > ... the git mirror I follow (git://git.kernel.dk/data/git/qemu.git) ...
Now, that is funny. You quote me, and you quote Rob, but culled both of
us from the Cc list.
Re: [Qemu-devel] What does code_copy_enabled do?
Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> Any news on the possible cvs->svn migration?
To be perfectly honest, IMO there is little point moving an existing
project from CVS to SVN. SVN has better support for renames, and a
few other advantages, but branching is still pretty catastrophic.
Any of the currently popular drcs's would be a big improvement. In
particular it would make it much easier to do development on changes
that don't want to go in CVS mainline for any reason.
Ian.
Re: [Qemu-devel] What does code_copy_enabled do?
Johannes Schindelin writes ("Re: Git/SVN/CVS? was Re: [Qemu-devel] What does
code_copy_enabled do?"):
> Just clone git://repo.or.cz/qemu.git, then.
Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> ... the git mirror I follow (git://git.kernel.dk/data/git/qemu.git) ...
Ideally it would be good for those of us who don't like CVS, and who
want to be a bit more profligate with accepting patches, to be able to
pull from each others' trees.
As I understand it that really means at the very least that there
ought to be one official git tree mirrored from CVS.
I assume that all of these mirrors are made using git-cvsimport in the
most usual way ? The associated websites are a bit sparse. It would
be nicer, if we were going to have something to base our work on, to
have a repository which is updated by cron and publicly available.
I'd be happy to either use an existing mirror or to set one up.
Ian.
[Qemu-devel] (resend) Allow setting the vendor and model_id strings with x86's -cpu option
Would you consider the following patch, that allows users to set two
important x86 cpu options from the command line? (the vendor and
model_id strings)
Every once in a while I am resending this little patch. It had generated
a lot of interest when it included silly bugs, but now it seems to be
largely ignored. However, it is important if one would like qemu to
impersonate a cpu closely as possible.
Regards,
Dan.
commit 04433bad959a7a4c1b8a0c22bd50eab9bf181b32
Author: Dan Kenigsberg <[EMAIL PROTECTED]>
Date: Thu Dec 20 15:43:15 2007 +0200
Change vendor string and model id from the -cpu command line option
diff --git a/target-i386/helper2.c b/target-i386/helper2.c
index 551a0d8..b59bf92 100644
--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -121,6 +121,7 @@ typedef struct x86_def_t {
const char *name;
uint32_t level;
uint32_t vendor1, vendor2, vendor3;
+char model_id[48];
int family;
int model;
int stepping;
@@ -262,7 +263,21 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def,
const char *cpu_model)
goto error;
}
x86_cpu_def->stepping = stepping;
-} else {
+} else if (!strcmp(featurestr, "vendor")) {
+if (strlen(val) != 12) {
+fprintf(stderr, "vendor string must be 12 chars long\n");
+x86_cpu_def = 0;
+goto error;
+}
+x86_cpu_def->vendor1 = x86_cpu_def->vendor2 =
x86_cpu_def->vendor3 = 0;
+for(i = 0; i < 4; i++) {
+x86_cpu_def->vendor1 |= ((unsigned char)val[i]) << (8
* i);
+x86_cpu_def->vendor2 |= ((unsigned char)val[i + 4]) << (8
* i);
+x86_cpu_def->vendor3 |= ((unsigned char)val[i + 8]) << (8
* i);
+}
+} else if (!strcmp(featurestr, "model_id"))
+strncpy(x86_cpu_def->model_id, val, 48);
+else {
fprintf(stderr, "unrecognized feature %s\n", featurestr);
x86_cpu_def = 0;
goto error;
@@ -323,13 +338,14 @@ static int cpu_x86_register (CPUX86State *env, const char
*cpu_model)
env->cpuid_ext3_features = def->ext3_features;
{
const char *model_id = "QEMU Virtual CPU version " QEMU_VERSION;
-int c, len, i;
-len = strlen(model_id);
+int c = -1, i;
+
+if (def->model_id[0] != '\0')
+model_id = def->model_id;
+
for(i = 0; i < 48; i++) {
-if (i >= len)
-c = '\0';
-else
-c = model_id[i];
+if (c != '\0')
+c = (unsigned char)model_id[i];
env->cpuid_model[i >> 2] |= c << (8 * (i & 3));
}
}
Re: [Qemu-devel] Using gdb to debug early kernel boot?
On Feb 11, 2008, at 9:29 AM, Rob Landley wrote: I'm trying to use gdb -s to debug the early boot of the sh4 kernel, but it's not liking me. It does this: qemu-system-sh4 -s -S -M r2d -kernel arch/sh/boot/zImage ... wait for gdb ... qemu: fatal: Trying to execute code outside RAM or ROM at 0x88800058 pc=0x88800058 sr=0x40f0 pr=0x fpscr=0x00040001 r0=0x88800058 r1=0xabe0 r2=0xdc80 r3=0x8880 r4=0x410ed11e r5=0xd211c711 r6=0x89253020 r7=0xd0193208 r8=0x2019e1e0 r9=0x6103d30f r10=0x64123128 r11=0x56125511 r12=0x r13=0x r14=0x r15=0x r16=0x r17=0x40f0 r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x Aborted (core dumped) (Which is the same behavior without -s -S). Over in the gdb session, I run gdb vmlinux and then: This means that qemu is unable to handle something, whatever that something might be. As soon as this happens, qemu quits and doesn't tell gdb anything about it. So in gdb's side the gdbserver simply died, which results in a watchdog timeout. (gdb) target remote localhost:1234 Remote debugging using localhost:1234 warning: shared library handler failed to enable breakpoint 0x in ?? () (gdb) c Continuing. Watchdog has expired. Target detached. (gdb) At which point the qemu instance in the other window has crashed. Am I doing it wrong? You might want to set a breakpoint at a pc where the virtual machine still lives. I guess that's 0x88800058 for you, so a "break *0x88800058" might help here. You could also enable in_asm debugging (if that's available on sh4) and take a look at the last translated chunk to find a reasonable address to break on. Alex
[Qemu-devel] Using gdb to debug early kernel boot?
I'm trying to use gdb -s to debug the early boot of the sh4 kernel, but it's not liking me. It does this: > qemu-system-sh4 -s -S -M r2d -kernel arch/sh/boot/zImage ... wait for gdb ... > qemu: fatal: Trying to execute code outside RAM or ROM at 0x88800058 > > pc=0x88800058 sr=0x40f0 pr=0x fpscr=0x00040001 > r0=0x88800058 r1=0xabe0 r2=0xdc80 r3=0x8880 > r4=0x410ed11e r5=0xd211c711 r6=0x89253020 r7=0xd0193208 > r8=0x2019e1e0 r9=0x6103d30f r10=0x64123128 r11=0x56125511 > r12=0x r13=0x r14=0x r15=0x > r16=0x r17=0x40f0 r18=0x r19=0x > r20=0x r21=0x r22=0x r23=0x > Aborted (core dumped) (Which is the same behavior without -s -S). Over in the gdb session, I run gdb vmlinux and then: > (gdb) target remote localhost:1234 > Remote debugging using localhost:1234 > warning: shared library handler failed to enable breakpoint > 0x in ?? () > (gdb) c > Continuing. > Watchdog has expired. Target detached. > (gdb) At which point the qemu instance in the other window has crashed. Am I doing it wrong? Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
