This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patch to add QNX NTO i386 support


"Kris Warkentin" <kewarken@qnx.com> writes:

> As long as I'm asking questions, below is what I've reduced our tm-i386nto.h
> file to.  Is it absolutely verboten to have this file?

The goal is to get rid of the tm.h files.  Adding new stuff to tm.h
files that will be difficult to get rid of would be rather
counterproductive.  As Andrew already mentioned, having the shared
library stuff in your tm-i386nto.h file would be acceptable; it
represents a problem we'll have to solve anyway so it doesn't burden
us with an additional problem.  The real-time signal stuff in
tm-qnxnto.h is fine too for similar reasons.

> There are a few handy definitions there like EXTRA_GDBINIT and so on
> that we like to define per target.  Also, I couldn't see how to get
> rid of the solib stuff.  Is there some place else I can put these
> definitions?

See my comments below.

> cheers,
> 
> Kris


> #ifndef TM_I386QNX_H
> #define TM_I386QNX_H 1

Please use TM_I386NTO_H if your file is called tm-i386nto.h.

> 
> /* Pick up most of what we need from the generic i386 target include file.
> */
> 
> #include "i386/tm-i386.h"
> #include "tm-qnxnto.h"

The tm-qnxnto.h will need to be considered too.  See even further below.

> #define __QNXTARGET__
> #define QNX_TARGET_CPUTYPE CPUTYPE_X86

These should really be avoided here.  Since they're only used in files listed in NATDEPFILES, these definitions could be moved to your nm.h file.

> /* After a watchpoint trap, the PC points to the instruction after
>    the one that caused the trap.  Therefore we don't need to step over it.
>    But we do need to reset the status register to avoid another trap.  */
> #define HAVE_CONTINUABLE_WATCHPOINT

Hmm, this poses an interesting problem.  The other i386 targets have
this in their nm.h file, since they consider hardware watchpoints as a
native-only feature.  However, this isn't necessarily right since we
might support hardware breakpoints via the remote protocol.  If you
can live with the native-only approach, please move this to your nm.h
file.  Otherwise we might need to multi-arch this definition.

> /* default processor for search path for libs */
> #define SOLIB_PROCESSOR "x86"

I think the feature that you need this define for is interesting, but
this file is the wrong place to set it.  It'd be better to implement
this feature in a less QNX-specific way, and let configure handle the
necessary configuration details.  

> /* Use .ntox86-gdbinit */
> #define EXTRA_GDBINIT_FILENAME ".ntox86-gdbinit"

Likewise.

> #define HANDLE_SVR4_EXEC_EMULATORS 1
> #include "solib.h" /* shared lib support */

Including solib.h is fine.  However I wonder why you need
HANDLE_SVR4_EXEC_EMULATORS.  AFAIK this deals with Solaris BCP
(running SunOS 4 a.out files on Solaris 2 a.k.a. SunOS 5).  What is
its relevance on QNX?  Could this be the reason that you need to set
SOLIB_BKPT_NAME?

> #endif /* ifndef TM_I386QNX_H */

Here is the meat from tm-qnxnto.h that needs some discussion.

Please add protection against multiple inclusion to this file.

+ #define __QNXTARGET__

Same story as above.

+ #include "tm-sysv4.h"

Shared library stoof so OK.

+ #define FIND_NEW_THREADS qnx_find_new_threads
+ void qnx_find_new_threads PARAMS ((void));

FIND_NEW_THREADS has been obsoleted quite some time ago.

+ #define target_pid_to_str(PTID) \
+       qnx_pid_to_str(PTID)
+ extern char *qnx_pid_to_str PARAMS ((ptid_t ptid));

This is not quite right.  I'm afraid that getting your target to debug
multi-threaded programs will incolve some serious work.

+ /* Setup the valid realtime signal range. */
+ #define REALTIME_LO 41
+ #define REALTIME_HI 56
+ 
+ /* Set up the undefined useable signals. */
+ #define RAW_SIGNAL_LO 32
+ #define RAW_SIGNAL_HI (REALTIME_LO - 1)
+ 
+ #define TARGET_SIGNAL_RAW_VALUES \
+ TARGET_SIGNAL_RAW0, \
+ TARGET_SIGNAL_RAW1, \
+ TARGET_SIGNAL_RAW2, \
+ TARGET_SIGNAL_RAW3, \
+ TARGET_SIGNAL_RAW4, \
+ TARGET_SIGNAL_RAW5, \
+ TARGET_SIGNAL_RAW6, \
+ TARGET_SIGNAL_RAW7, \
+ TARGET_SIGNAL_RAW8
+ 
+ #define TARGET_SIGNAL_RAW_TABLE \
+ {"SIGNAL32", "Signal 32"}, \
+ {"SIGNAL33", "Signal 33"}, \
+ {"SIGNAL34", "Signal 34"}, \
+ {"SIGNAL35", "Signal 35"}, \
+ {"SIGNAL36", "Signal 36"}, \
+ {"SIGNAL37", "Signal 37"}, \
+ {"SIGNAL38", "Signal 38"}, \
+ {"SIGNAL39", "Signal 39"}, \
+ {"SIGNAL40", "Signal 40"}

This signal stuff is OK for now.

+ /* See solib-svr4.c
+  * This works around a problem with static binaries.  An internal breakpoint
+  * is set on _start but for whatever reason, gdb doesn't handle it properly
+  * and claims a SIGTRAP has been raised on the inferior.  If we move the
+  * shlib_event breakpoint ahead to main (this already happened by default
+  * on sh for some reason), then it works.  FIXME: we need to discover why
+  * gdb isn't handling breakpoints properly at the early stages of execution. */
+ #define SOLIB_BKPT_NAME "main"

Hmm, we shouldn't need any shlib_event breakpoint for static
binaries...  This workaround should be OK for now.  The style of the
comment is violating our coding standards though; please remove the *
at the beginning of the lines.


Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]