1 Feb 2004 03:01
1 Feb 2004 18:02
[RFC] TARGET_OBJECT_WCOOKIE
Mark Kettenis <kettenis <at> chello.nl>
2004-02-01 17:02:17 GMT
2004-02-01 17:02:17 GMT
Actually the purpose of this RFC is twofold. First, I'd like to add a TARGET_OBJECT_WCOOKIE method to support the StackGhost cookie on OpenBSD/sparc. This really is something target-related rather than OS/ABI related. GDB will have to deal with StackGhost when running non-OpenBSD binaries on an OpenBSD kernel. Moreover, older OpenBSD kernels might not have StackGhost. Anyway, are there objections to adding something like the attached patch? The second issue I'd like your opinion on is related to the patch. I followed the example set by TARGET_OBJECT_UNWIND_TABLE in having a macro (NATIVE_XFER_WCOOKIE) to invoke the native-specific function that fetches the cookie. This macro would be defined in the nm.h file, but wasn't it our goal to get rid of the nm.h file sooner rather than later? Shouldn't we add another method for these kinds of hooks? The obvious alternatives are: a) Use a public function pointer, which is initialized to some do-nothing-and-return-minus-one function by default. This function pointer would be overridden by some code in the appropraite *-nat.c files. b) Use a private function pointer, and provide a function to set that pointer, along the lines of inftarg_set_find_memory_regions(). Opinions? Mark Index: inftarg.c(Continue reading)
1 Feb 2004 18:48
Re: [RFC] Non-executable stack on SPARC
Mark Kettenis <kettenis <at> chello.nl>
2004-02-01 17:48:19 GMT
2004-02-01 17:48:19 GMT
Date: 27 Jan 2004 09:56:52 +0200 From: Eli Zaretskii <eliz <at> elta.co.il> > Date: Mon, 26 Jan 2004 13:42:30 +0100 (CET) > From: Mark Kettenis <kettenis <at> chello.nl> > > With my patch, > or with the suggestions I made below, GDB will usually still see > SIGSEG under normal circumstances. GDB will only convert such a > signal into SIGTRAP if there's a breakpoint inserted at the point > where the inferior stopped. Where is this last condition tested to be true? The if clause where you wanted to add SIGSEGV doesn't test that, I think. It's quite a bit further down where this gets resolved; see infrun.c:1962. The signal is only converted into SIGTRAP if the signal can be explained by a breakpoint. > As to punting the SIGSEGV to SIGTRAP conversion to the architecture: > we could do this in target_wait() or target_wait_hook(), but that > would offload it to the target we're running on and not to the > architecture. So perhaps we need an architecture way to do such conversions. My line of thought is that it's IMHO fundamentally wrong to push target- or architecture-specific details into the application level of GDB, which is what infrun.c is. infrun.c should deal with high-level logic of handling a stopped inferior, it should not IMHO know about(Continue reading)
1 Feb 2004 18:54
Re: [RFC] Non-executable stack on SPARC
Mark Kettenis <kettenis <at> chello.nl>
2004-02-01 17:54:29 GMT
2004-02-01 17:54:29 GMT
Date: Mon, 26 Jan 2004 11:21:01 -0500 From: Andrew Cagney <cagney <at> gnu.org> > A while ago, I established that getting inferior function calls on > SPARC working with a non-executable stack is remarkably simple. Just > acknowledging that breakpoint instructions may cause SIGSEGV, as per > the attached patch, is enough. However, some people were afraid that > blindly applying this patch might cause some problems on other > targets. I think there are two alternatives: I thought the original patch was already committed?(Continue reading)Only to the branch. > 1. Only check for SIGSEGV if the target in question uses "ON_STACK" > for its call_dummy_location. A more robust check would be to confirm that a breakpoint is at that address (naturally ignoring decr pc after break
. However, does later code check exactly that - confirming that the breakpoint explains the stop reason? Yes. > 2. Add a new method to the architecture vector to check whether a > particular signal may have been the result of a breakpoint > instruction. Suggested name & signature: > > int breakpoint_signal_p (struct gdbarch *gdbarch, int signal)
1 Feb 2004 21:08
Re: [RFC] Non-executable stack on SPARC
Eli Zaretskii <eliz <at> elta.co.il>
2004-02-01 20:08:49 GMT
2004-02-01 20:08:49 GMT
> Date: Sun, 1 Feb 2004 18:48:19 +0100 (CET) > From: Mark Kettenis <kettenis <at> chello.nl> > > My line of thought is that it's IMHO fundamentally wrong to push > target- or architecture-specific details into the application level of > GDB, which is what infrun.c is. infrun.c should deal with high-level > logic of handling a stopped inferior, it should not IMHO know about > intricacies of specific targets. > > The question is to what extent this is an intricacy of a specific > target. I think that the set of signals, apart of SIGTRAP, that can express a breakpoint on a given target/architecture is something infrun.c shouldn't know about.
1 Feb 2004 21:23
Re: [RFC] TARGET_OBJECT_WCOOKIE
Daniel Jacobowitz <drow <at> mvista.com>
2004-02-01 20:23:13 GMT
2004-02-01 20:23:13 GMT
On Sun, Feb 01, 2004 at 06:02:17PM +0100, Mark Kettenis wrote: > Actually the purpose of this RFC is twofold. > > First, I'd like to add a TARGET_OBJECT_WCOOKIE method to support the > StackGhost cookie on OpenBSD/sparc. This really is something > target-related rather than OS/ABI related. GDB will have to deal with > StackGhost when running non-OpenBSD binaries on an OpenBSD kernel. > Moreover, older OpenBSD kernels might not have StackGhost. Anyway, > are there objections to adding something like the attached patch? Not from me. > The second issue I'd like your opinion on is related to the patch. I > followed the example set by TARGET_OBJECT_UNWIND_TABLE in having a > macro (NATIVE_XFER_WCOOKIE) to invoke the native-specific function > that fetches the cookie. This macro would be defined in the nm.h > file, but wasn't it our goal to get rid of the nm.h file sooner rather > than later? Shouldn't we add another method for these kinds of hooks? > The obvious alternatives are: > > a) Use a public function pointer, which is initialized to some > do-nothing-and-return-minus-one function by default. This function > pointer would be overridden by some code in the appropraite *-nat.c > files. > > b) Use a private function pointer, and provide a function to set that > pointer, along the lines of inftarg_set_find_memory_regions(). > > Opinions?(Continue reading)
2 Feb 2004 19:27
Re: [RFC] Non-executable stack on SPARC
Andrew Cagney <cagney <at> gnu.org>
2004-02-02 18:27:24 GMT
2004-02-02 18:27:24 GMT
> Assuming that for VLIW gdb replaces the entire instruction bundle with a > breakpoint, a breakpoint instruction can only ever generate a sigtrap > (et.al.) (if executed) or sigsegv (if not accessible) so provided there > is a breakpoint at the PC I don't think there is any possability of > confusion (but again ignore decr pc after break
2 Feb 2004 19:37
Re: [RFC] Non-executable stack on SPARC
Andrew Cagney <cagney <at> gnu.org>
2004-02-02 18:37:20 GMT
2004-02-02 18:37:20 GMT
> Date: Sun, 1 Feb 2004 18:48:19 +0100 (CET) >> From: Mark Kettenis <kettenis <at> chello.nl> >> >> My line of thought is that it's IMHO fundamentally wrong to push >> target- or architecture-specific details into the application level of >> GDB, which is what infrun.c is. infrun.c should deal with high-level >> logic of handling a stopped inferior, it should not IMHO know about >> intricacies of specific targets. >> >> The question is to what extent this is an intricacy of a specific >> target. > > > I think that the set of signals, apart of SIGTRAP, that can express a > breakpoint on a given target/architecture is something infrun.c > shouldn't know about. Yes. Here, though, we don't have the case of a just-executed breakpoint, rather we have a not-yet-executed segmentation fault. To implement VM based breakpoints and watchpoints GDB will need to be able to differentiate between the two. Hence, I think making this edge case visible in infrun is better. enjoy, Andrew
2 Feb 2004 20:01
Re: [RFC] TARGET_OBJECT_WCOOKIE
Andrew Cagney <cagney <at> gnu.org>
2004-02-02 19:01:48 GMT
2004-02-02 19:01:48 GMT
>>The second issue I'd like your opinion on is related to the patch. I >> followed the example set by TARGET_OBJECT_UNWIND_TABLE in having a >> macro (NATIVE_XFER_WCOOKIE) to invoke the native-specific function >> that fetches the cookie. This macro would be defined in the nm.h >> file, but wasn't it our goal to get rid of the nm.h file sooner rather >> than later? Shouldn't we add another method for these kinds of hooks? >> The obvious alternatives are: >> >> a) Use a public function pointer, which is initialized to some >> do-nothing-and-return-minus-one function by default. This function >> pointer would be overridden by some code in the appropraite *-nat.c >> files. >> b) Use a private function pointer, and provide a function to set that >> pointer, along the lines of inftarg_set_find_memory_regions(). >> Opinions? It sux less than some of the other existing alternatives - in particular the way certain /proc or ptrace specific functions just happen to be linked in. Makes a real mess of the idea of having both /proc and ptrace support in a single executable. > Personally, I think the -nat files should have a chance to edit > child_ops, or provide their own version of child_ops. This would > eliminate 90% of the gunk in nm* files which is checked in the various > inf* files implementing child_ops. Have "proc" and "ptrace" export functions for creating fairly generic target ops and then have *-nat "inherit" from it (or push on-top of it)?(Continue reading)
2 Feb 2004 20:25
gdb "bad physname", no c++ symbols or stack
james pentland <james_pentland <at> yahoo.com>
2004-02-02 19:25:36 GMT
2004-02-02 19:25:36 GMT
i have built a program consisting of mostly c++ sources with gcc. when i try to debug it with gdb, almost none of the functions or other symbols can be referenced for breakpointing or otherwise. i can not get a list of functions. i can not get listing information for any c++ source. i was able to put a break point in one of the c sources. when the program stopped there, the stack trace effectively disappeared when it ascended up into the c++ routines. there is a consistent complaint to many of these commands as follows: bad physname _ZNSt15const_mem_fun_tIv11packagemetaEC1EMS0_KFvvE what might be wrong? some debugging session output is shown below. $ gcc --version gcc (GCC) 3.2 20020927 (prerelease) Copyright (C) 2002 Free Software Foundation, Inc. $ gdb setup GNU gdb 2002-12-19-cvs (cygwin-special)(Continue reading)
RSS Feed