From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: grossman@juniper.net Cc: gdb-patches@sources.redhat.com Subject: Re: Patches for FreeBSD 4.2 Date: Fri, 13 Jul 2001 08:16:00 -0000 Message-id: <200107131515.f6DFFvt02063@delius.kettenis.local> References: <200107110639.f6B6d4K28642@ploor.juniper.net> <15182.7531.854668.426294@gundor.juniper.net> X-SW-Source: 2001-07/msg00325.html From: Stu Grossman Date: Thu, 12 Jul 2001 14:58:03 -0700 Actually, I was following the linux convention (xxx-linux-yyy.c). But, I can fix it. As an aside, it would be nice to use a consistent file naming convention throughout GDB. So far, we have -nat/tdep, or --nat/tdep. Mostly, files seem to use the latter convention unless it's one of the BSDs, in which case they use the former. Picking one convention and sticking to it would make things cleaner. New files tend to use the latter convention, but let's stick to -nat/dep for the BSDs. > * This file won't compile on FreeBSD 3.x, since > doesn't exist. I'll try to clean that up for 3.x. It looks like in 3.x and earlier, struct sigframe was in . Looks like it, but we may not need that. > Besides, the implementation of a *_frame_saved_pc > function belongs in a target-dependent file, and shouldn't depend on > the target headers. What's wrong with the old implementation? I disagree. *_frame_saved_pc is inherently native dependent for most OS's as it involves looking at some kind of OS specific signal context structure. Well, it's true that it's OS specific, but that doesn't mean that it's native dependent. A cross debugger should be able to trace back through signal frames just as well as a native debugger. The only thing that's needed is that instead of relying on target headers such as to provide the necessary offsets, we must simply hardcode the values into GDB. That's what I did when I updated the FreeBSD support some time ago. Now hardcoding has a drawback. When the signal frame layout changes (as it did between FreeBSD 3 and FreeBSD 4) things break. That's too bad, but it is a change in the ABI, and there's nothing we can do about it if we don't have the target headers available (and even then it is problematic since the location of the relevant details is often changed between different releases of an OS). The best we can do is somehow override these hardcoded values when building a native debugger. I have an idea to implement that makes multi-arching the i386 target easier. It would really help if you could send me the numerical value of PS_STRINGS on FreeBSD 4.2. I'll go and test my version of sigtramp code a bit. If it works, that part of your patch will not be necessary. I think you are stuck with different versions of GDB anyway. 3.4 seems to have two versions of sigcontext (the old one is called `osigcontext'). Sigcontext is pretty much the same as the 4.2 version. In any case, I don't see a good way to distinguish between the two versions of sigcontext. In addition, I doubt that core files are compatible between 3.4 and 4.2. So, it really looks like you want different builds of GDB for each OS version. The idea of a multi-arch GDB is that it contains support for multiple targets in a single GDB. It might be necessary for the user to explicitly set the target if distinguishing between them isn't possible, but that's no reason not to add support for different versions of FreeBSD. > * I think the SOFTWARE_SINGLE_STEP_P stuff can be removed from your > version of child_resume. That is only used for an internal consistency check, which I think is valuable here. It's not as important as for the generic version to have this check, but it doesn't hurt, so feel free to leave it in. Mark