* Re: Mingw GDB build fails for M16C target [not found] <82C3BC9106BCE149B63464D79D0A22FD0A68110C@sohm.kpit.com> @ 2009-04-28 22:57 ` Kevin Buettner 2009-04-29 2:35 ` Daniel Jacobowitz 2009-05-08 22:57 ` Kevin Buettner 0 siblings, 2 replies; 7+ messages in thread From: Kevin Buettner @ 2009-04-28 22:57 UTC (permalink / raw) To: gdb-patches, jimb; +Cc: Mahesh Basavaraj Shavari, gdb [Note: Reply-to has been set to gdb-patches.] On Sat, 25 Apr 2009 11:05:25 +0530 Mahesh Basavaraj Shavari <Mahesh.Shavari@kpitcummins.com> wrote: > /home/mahesh/GDB/gdb-6.8/gdb-6.8.50.20080811/sim/m32c/gdb-if.c:541: > error: `SIGTRAP' undeclared (first use in this function) Mahesh, Please try the patch below and let me know if it works for you. Jim, It appears to me that comment, "Oddly, the gdb/sim interface uses host signal numbers...", isn't true. My patch deletes this comment in addition to using TARGET_SIGNAL_foo instead of SIGfoo. If you look at remote-sim.c, you'll see that `enum target_signal' (which defines the various TARGET_SIGNAL_foo constants) is used throughout the file. Okay to apply? Kevin * m32c/gdb-if.c (m32c_signal_to_host): Rename to m32c_signal_to_target. Change signal return values from SIGILL, SIGTRAP, SIGSEGV, etc. to TARGET_SIGNAL_ILL, TARGET_SIGNAL_TRAP, TARGET_SIGNAL_SEGV, etc. Fix all callers. Index: m32c/gdb-if.c =================================================================== RCS file: /cvs/src/src/sim/m32c/gdb-if.c,v retrieving revision 1.7 diff -u -p -r1.7 gdb-if.c --- m32c/gdb-if.c 14 Jan 2009 10:53:07 -0000 1.7 +++ m32c/gdb-if.c 28 Apr 2009 22:38:44 -0000 @@ -523,52 +523,35 @@ int siggnal; /* Given a signal number used by the M32C bsp (that is, newlib), - return a host signal number. (Oddly, the gdb/sim interface uses - host signal numbers...) */ + return a target signal number used by GDB. */ int -m32c_signal_to_host (int m32c) +m32c_signal_to_target (int m32c) { switch (m32c) { case 4: -#ifdef SIGILL - return SIGILL; -#else - return SIGSEGV; -#endif + return TARGET_SIGNAL_ILL; case 5: - return SIGTRAP; + return TARGET_SIGNAL_TRAP; case 10: -#ifdef SIGBUS - return SIGBUS; -#else - return SIGSEGV; -#endif + return TARGET_SIGNAL_BUS; case 11: - return SIGSEGV; + return TARGET_SIGNAL_SEGV; case 24: -#ifdef SIGXCPU - return SIGXCPU; -#else - break; -#endif + return TARGET_SIGNAL_XCPU; case 2: - return SIGINT; + return TARGET_SIGNAL_INT; case 8: -#ifdef SIGFPE - return SIGFPE; -#else - break; -#endif + return TARGET_SIGNAL_FPE; case 6: - return SIGABRT; + return TARGET_SIGNAL_ABRT; } return 0; @@ -588,7 +571,7 @@ handle_step (int rc) else if (M32C_STOPPED (rc)) { reason = sim_stopped; - siggnal = m32c_signal_to_host (M32C_STOP_SIG (rc)); + siggnal = m32c_signal_to_target (M32C_STOP_SIG (rc)); } else { ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mingw GDB build fails for M16C target 2009-04-28 22:57 ` Mingw GDB build fails for M16C target Kevin Buettner @ 2009-04-29 2:35 ` Daniel Jacobowitz 2009-04-29 19:51 ` Kevin Buettner 2009-05-08 22:57 ` Kevin Buettner 1 sibling, 1 reply; 7+ messages in thread From: Daniel Jacobowitz @ 2009-04-29 2:35 UTC (permalink / raw) To: gdb-patches On Tue, Apr 28, 2009 at 03:57:24PM -0700, Kevin Buettner wrote: > Jim, > > It appears to me that comment, "Oddly, the gdb/sim interface uses host > signal numbers...", isn't true. My patch deletes this comment in > addition to using TARGET_SIGNAL_foo instead of SIGfoo. If you look at > remote-sim.c, you'll see that `enum target_signal' (which defines the > various TARGET_SIGNAL_foo constants) is used throughout the file. Shouldn't this be the same as common/sim-signal.c? sim_signal_to_host uses native numbers and sim_signal_to_target uses GDB protocol numbers. Then again, I'm totally baffled by this bit of the sim. It looks like sim_stop_reason returns a target signal and the callers check it against a host signal??? -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mingw GDB build fails for M16C target 2009-04-29 2:35 ` Daniel Jacobowitz @ 2009-04-29 19:51 ` Kevin Buettner 2009-04-29 20:01 ` Daniel Jacobowitz 0 siblings, 1 reply; 7+ messages in thread From: Kevin Buettner @ 2009-04-29 19:51 UTC (permalink / raw) To: gdb-patches On Tue, 28 Apr 2009 22:35:11 -0400 Daniel Jacobowitz <drow@false.org> wrote: > On Tue, Apr 28, 2009 at 03:57:24PM -0700, Kevin Buettner wrote: > > Jim, > > > > It appears to me that comment, "Oddly, the gdb/sim interface uses host > > signal numbers...", isn't true. My patch deletes this comment in > > addition to using TARGET_SIGNAL_foo instead of SIGfoo. If you look at > > remote-sim.c, you'll see that `enum target_signal' (which defines the > > various TARGET_SIGNAL_foo constants) is used throughout the file. > > Shouldn't this be the same as common/sim-signal.c? sim_signal_to_host > uses native numbers and sim_signal_to_target uses GDB protocol > numbers. It's not clear to me what you're asking about. If you're asking why m32c/gdb-if.c doesn't use common/sim-signal.c, that's because the m32c sim doesn't use the infrastructure in common/ at all. If you're asking why I don't simply copy sim_signal_to_target for use in m32c/gdb-if.c, that's because the m32c sim doesn't use the SIM_SIGfoo constants that common/sim-signal.c uses. It does bother me though that m32c_signal_to_target() uses hardcoded constants like 4, 5, 10, 11, etc. I suspect it was done this way because including the correct newlib header file (without conflict with certain system headers) was difficult. That's just a guess though. > Then again, I'm totally baffled by this bit of the sim. It looks like > sim_stop_reason returns a target signal and the callers check it > against a host signal??? I looked at that yesterday prior to posting my patch. I thought I understood what was going on, but now that I look at it closer, I too am baffled. I noticed yesterday that signal() is being called to handle SIGINT. My thought at the time was that the handler was somehow manipulating the sim's state so that it would return the sim specific code for the signal. But that's not what's happening. The handler simply checks to make sure that it (the sim) is not stopped; if not, it prints a message, and then exits. So it seems to me that sim_signal_to_host() and that check that you mention are completely unnecessary. Kevin ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mingw GDB build fails for M16C target 2009-04-29 19:51 ` Kevin Buettner @ 2009-04-29 20:01 ` Daniel Jacobowitz 2009-04-29 20:27 ` Kevin Buettner 0 siblings, 1 reply; 7+ messages in thread From: Daniel Jacobowitz @ 2009-04-29 20:01 UTC (permalink / raw) To: gdb-patches On Wed, Apr 29, 2009 at 12:50:49PM -0700, Kevin Buettner wrote: > > Shouldn't this be the same as common/sim-signal.c? sim_signal_to_host > > uses native numbers and sim_signal_to_target uses GDB protocol > > numbers. > > It's not clear to me what you're asking about. > > If you're asking why m32c/gdb-if.c doesn't use common/sim-signal.c, > that's because the m32c sim doesn't use the infrastructure in common/ > at all. > > If you're asking why I don't simply copy sim_signal_to_target for > use in m32c/gdb-if.c, that's because the m32c sim doesn't use the > SIM_SIGfoo constants that common/sim-signal.c uses. It does bother me > though that m32c_signal_to_target() uses hardcoded constants like 4, > 5, 10, 11, etc. I suspect it was done this way because including the > correct newlib header file (without conflict with certain system > headers) was difficult. That's just a guess though. I was actually asking about sim_signal_to_host, since this was m32c_signal_to_host. The sim_ version uses SIGILL, SIGTRAP, etc. > > Then again, I'm totally baffled by this bit of the sim. It looks like > > sim_stop_reason returns a target signal and the callers check it > > against a host signal??? > > I looked at that yesterday prior to posting my patch. I thought I > understood what was going on, but now that I look at it closer, I > too am baffled. I noticed yesterday that signal() is being called to > handle SIGINT. My thought at the time was that the handler was > somehow manipulating the sim's state so that it would return the sim > specific code for the signal. But that's not what's happening. The > handler simply checks to make sure that it (the sim) is not stopped; > if not, it prints a message, and then exits. So it seems to me that > sim_signal_to_host() and that check that you mention are completely > unnecessary. Yes... I don't think any of the conversion routines that use host numbers should be there. I'm not feeling ambitious enough to remove them from all sims, but perhaps you can get just m32c? -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mingw GDB build fails for M16C target 2009-04-29 20:01 ` Daniel Jacobowitz @ 2009-04-29 20:27 ` Kevin Buettner 2009-04-29 20:33 ` Daniel Jacobowitz 0 siblings, 1 reply; 7+ messages in thread From: Kevin Buettner @ 2009-04-29 20:27 UTC (permalink / raw) To: gdb-patches On Wed, 29 Apr 2009 16:01:24 -0400 Daniel Jacobowitz <drow@false.org> wrote: > > If you're asking why I don't simply copy sim_signal_to_target for > > use in m32c/gdb-if.c, that's because the m32c sim doesn't use the > > SIM_SIGfoo constants that common/sim-signal.c uses. It does bother me > > though that m32c_signal_to_target() uses hardcoded constants like 4, > > 5, 10, 11, etc. I suspect it was done this way because including the > > correct newlib header file (without conflict with certain system > > headers) was difficult. That's just a guess though. > > I was actually asking about sim_signal_to_host, since this was > m32c_signal_to_host. The sim_ version uses SIGILL, SIGTRAP, etc. Wow, did I guess wrong. My patch changes the name from m32c_signal_to_host() to m32c_signal_to_target() and switches from use of host-based numbers to target-specific numbers. > Yes... I don't think any of the conversion routines that use host > numbers should be there. I'm not feeling ambitious enough to remove > them from all sims, but perhaps you can get just m32c? Yes, I have done this. See above. Kevin ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mingw GDB build fails for M16C target 2009-04-29 20:27 ` Kevin Buettner @ 2009-04-29 20:33 ` Daniel Jacobowitz 0 siblings, 0 replies; 7+ messages in thread From: Daniel Jacobowitz @ 2009-04-29 20:33 UTC (permalink / raw) To: gdb-patches On Wed, Apr 29, 2009 at 01:27:02PM -0700, Kevin Buettner wrote: > > Yes... I don't think any of the conversion routines that use host > > numbers should be there. I'm not feeling ambitious enough to remove > > them from all sims, but perhaps you can get just m32c? > > Yes, I have done this. See above. Gotcha now! Sounds good to me. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Mingw GDB build fails for M16C target 2009-04-28 22:57 ` Mingw GDB build fails for M16C target Kevin Buettner 2009-04-29 2:35 ` Daniel Jacobowitz @ 2009-05-08 22:57 ` Kevin Buettner 1 sibling, 0 replies; 7+ messages in thread From: Kevin Buettner @ 2009-05-08 22:57 UTC (permalink / raw) To: gdb-patches; +Cc: Mahesh Basavaraj Shavari On Tue, 28 Apr 2009 15:57:24 -0700 Kevin Buettner <kevinb@redhat.com> wrote: > * m32c/gdb-if.c (m32c_signal_to_host): Rename to > m32c_signal_to_target. Change signal return values from SIGILL, > SIGTRAP, SIGSEGV, etc. to TARGET_SIGNAL_ILL, TARGET_SIGNAL_TRAP, > TARGET_SIGNAL_SEGV, etc. Fix all callers. Jim sent me an approval for this patch. Committed. Kevin ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-05-08 22:57 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <82C3BC9106BCE149B63464D79D0A22FD0A68110C@sohm.kpit.com>
2009-04-28 22:57 ` Mingw GDB build fails for M16C target Kevin Buettner
2009-04-29 2:35 ` Daniel Jacobowitz
2009-04-29 19:51 ` Kevin Buettner
2009-04-29 20:01 ` Daniel Jacobowitz
2009-04-29 20:27 ` Kevin Buettner
2009-04-29 20:33 ` Daniel Jacobowitz
2009-05-08 22:57 ` Kevin Buettner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox