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.

Okay.

<snip>

> > #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.

Yes, you're right.  Since I've separated the native and remote stuff
properly, this will work.

>
> > /* 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.

Okay, file that under TODO along with the solib stuff.  We have hardware
breakpoints on all our remote targets that support them.

> > /* 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.

So something like adding an extra -D at configure time?

> > #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?

I'm not sure the legacy behind this.  All I know is that if it isn't
defined, we don't find the linker entry point in our libc.  I can look
further into it.  The SOLIB_BKPT_NAME worked around an issue with statically
linked binaries.  I never chased it further than coming up with the
workaround.  You have some ideas?

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

I cleaned this file yesterday.  There's basically nothing left but the
signal stuff.

> Please add protection against multiple inclusion to this file.

Yes.  Doh.

> + #define __QNXTARGET__
>
> Same story as above.

gone

> FIND_NEW_THREADS has been obsoleted quite some time ago.

I had already removed it.  This refactoring stuff is great.  Our port is
getting really clean.

> + #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.

Gone. Also would have been changed to nto_pid_to_str.

> + /* 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.

I thought I had run indent on all the files.  I might have missed
tm-qnxnto.h.  I've got a FIXME in there for future reference.  There's
definitely something up with our solib stuff as you can see but I don't
completely understand all the issues yet.

Thank you very much.  I've been more productive the last couple days than I
have in quite a while thanks to your and Andrew's help.

cheers,

Kris


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