Devel tools for PPC?

bridged with qdn.public.qnxrtp.powerpc
Paul D. Smith

Devel tools for PPC?

Post by Paul D. Smith » Sat Mar 30, 2002 1:56 am

Does anyone know where I can get development tools for QNX on PPC?

I have the Solaris development kit with cross-compilers, but I'd really
like to get at least make and _especially_ gdb native on the PPC. Where
can I find these? A co-worker has tried a hand at building them using
the cross-compiler environment and had _no_ luck. Surely someone must
have these pre-built for this platform!?!?


Then we tried to use remote debugging, and that _almost_ worked, except
not quite. We can get the GDB agent running on PPC and connect to it
from QNX in i86, the load the binary and even run it, but we are having
all kinds of problems with shared libraries: if we set the
LD_LIBRARY_PATH on the PPC before we run the GDB agent (and set the flag
in GDB that tells it to use the agent's environment), it just crashes
with some kind of error about not finding /ppcbe/lib/libc.so -- which is
right because that is the library on the i86 box, not the PPC box.

If we set LD_LIBRARY_PATH on the GDB side and tell it to use that, then
it works better: it runs and hits our first breakpoint but if we use "n"
or anything to step it goes right down the tubes.

Anyone have this working?

Help! Thanks...

--
-------------------------------------------------------------------------------
Paul D. Smith <pausmith@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.

Igor Kovalenko

Re: Devel tools for PPC?

Post by Igor Kovalenko » Tue Apr 02, 2002 7:24 am

Someone might have, surely. The make is fairly trivial, but gdb might be a
bitch. Perhaps you really want to look at the upcoming Eclipse stuff,
although Solaris version is not available yet. Nortel should have access,
afaik since their people were at the presentation.

-- igor

"Paul D. Smith" <pausmith@nortelnetworks.com> wrote in message
news:p5eli224zw.fsf@lemming.engeast.baynetworks.com...
Does anyone know where I can get development tools for QNX on PPC?

I have the Solaris development kit with cross-compilers, but I'd really
like to get at least make and _especially_ gdb native on the PPC. Where
can I find these? A co-worker has tried a hand at building them using
the cross-compiler environment and had _no_ luck. Surely someone must
have these pre-built for this platform!?!?


Then we tried to use remote debugging, and that _almost_ worked, except
not quite. We can get the GDB agent running on PPC and connect to it
from QNX in i86, the load the binary and even run it, but we are having
all kinds of problems with shared libraries: if we set the
LD_LIBRARY_PATH on the PPC before we run the GDB agent (and set the flag
in GDB that tells it to use the agent's environment), it just crashes
with some kind of error about not finding /ppcbe/lib/libc.so -- which is
right because that is the library on the i86 box, not the PPC box.

If we set LD_LIBRARY_PATH on the GDB side and tell it to use that, then
it works better: it runs and hits our first breakpoint but if we use "n"
or anything to step it goes right down the tubes.

Anyone have this working?

Help! Thanks...

--
--------------------------------------------------------------------------
-----
Paul D. Smith <pausmith@nortelnetworks.com> HASMAT--HA Software Mthds &
Tools
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist
--------------------------------------------------------------------------
-----
These are my opinions---Nortel Networks takes no responsibility for
them.

Paul D. Smith

Re: Devel tools for PPC?

Post by Paul D. Smith » Tue Apr 02, 2002 1:40 pm

%% "Igor Kovalenko" <kovalenko@attbi.com> writes:

ik> Someone might have, surely. The make is fairly trivial, but gdb
ik> might be a bitch. Perhaps you really want to look at the upcoming
ik> Eclipse stuff, although Solaris version is not available
ik> yet. Nortel should have access, afaik since their people were at
ik> the presentation.

All our development is done on Solaris and Linux right now (I'm trying
to move more to Linux, since it's faster for less $$). We don't have
any Windows or NT development. We're not in any way interested in
moving in that direction, either. (I'm speaking for my group, here, not
Nortel as a whole).

We will probably be doing most of our development using
cross-compilation, since we use ClearCase, so a "make" is not critical
(we could use it in order to run our unit test suite, though).

However, _some_ kind of debugging capability is obviously critical! We
can't do rapid development without source-level debugging. As I said I
would even settle for remote debugging, if I could get it to work. What
do others do for debugging on PPC?

--
-------------------------------------------------------------------------------
Paul D. Smith <pausmith@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.

Igor Kovalenko

Re: Devel tools for PPC?

Post by Igor Kovalenko » Wed Apr 03, 2002 5:15 am

We're pretty much in same boat except that out target is x86. Our
development is on Solaris as well and we also use Clearcase. Eclipse for
Solaris host should be coming out too, not sure when exactly. Meanwhile the
only out of box solution for PPC is Windows or QNX hosted tools. Doing
self-hosted PPC development tools is possible too, I've done that for x86 in
the past, as well as Solaris cross-envrionment (back then neither
self-hosted nor Solaris hosted was no available yet). It can be rather
messy and tricky job, but doable. QNX gave me enough stuff to start with and
guidance to get through those tasks, I bet they'd help you too.

-- igor

"Paul D. Smith" <pausmith@nortelnetworks.com> wrote in message
news:p5lmc6usl7.fsf@lemming.engeast.baynetworks.com...
%% "Igor Kovalenko" <kovalenko@attbi.com> writes:

ik> Someone might have, surely. The make is fairly trivial, but gdb
ik> might be a bitch. Perhaps you really want to look at the upcoming
ik> Eclipse stuff, although Solaris version is not available
ik> yet. Nortel should have access, afaik since their people were at
ik> the presentation.

All our development is done on Solaris and Linux right now (I'm trying
to move more to Linux, since it's faster for less $$). We don't have
any Windows or NT development. We're not in any way interested in
moving in that direction, either. (I'm speaking for my group, here, not
Nortel as a whole).

We will probably be doing most of our development using
cross-compilation, since we use ClearCase, so a "make" is not critical
(we could use it in order to run our unit test suite, though).

However, _some_ kind of debugging capability is obviously critical! We
can't do rapid development without source-level debugging. As I said I
would even settle for remote debugging, if I could get it to work. What
do others do for debugging on PPC?

--
--------------------------------------------------------------------------
-----
Paul D. Smith <pausmith@nortelnetworks.com> HASMAT--HA Software Mthds &
Tools
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist
--------------------------------------------------------------------------
-----
These are my opinions---Nortel Networks takes no responsibility for
them.

Paul D. Smith

Re: Devel tools for PPC?

Post by Paul D. Smith » Thu Apr 04, 2002 9:39 pm

I have to say I'm pretty bummed with QSSI's support of PPC so far. I
can't believe they don't even have a native debugger.

There's a bug in the gawk that they ship: it will not run unless you set
LD_LIBRARY_PATH to /lib. If you don't it fails with an error about
/lib/libm.so.2 not found (but it's right there!) I even tried using the
cross-compiler to build my own gawk and it has the identical problem.

I can't use -rpath to set an automatic place to look for shared libs;
this works on every other platform I build on except for QNX (both intel
and PPC). It's documented to work but it doesn't (QNX 6.1.0A).

I still can't get the remote debugger to work with my shared libraries
on PPC; I've had to switch back to static libraries.

--
-------------------------------------------------------------------------------
Paul D. Smith <pausmith@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.

Colin Burgess

Re: Devel tools for PPC?

Post by Colin Burgess » Thu Apr 04, 2002 10:29 pm

Hi Paul.

Paul D. Smith <pausmith@nortelnetworks.com> wrote:
I have to say I'm pretty bummed with QSSI's support of PPC so far. I
can't believe they don't even have a native debugger.
Right now we only support a native development environment on our
x86 platform. However, we do make the source code to our GNU tools available
for download if you wish to do your own thing with it (see developers.qnx.com)
There's a bug in the gawk that they ship: it will not run unless you set
LD_LIBRARY_PATH to /lib. If you don't it fails with an error about
/lib/libm.so.2 not found (but it's right there!) I even tried using the
cross-compiler to build my own gawk and it has the identical problem.
What do you have LD_LIBRARY_PATH set to when it fails?
I can't use -rpath to set an automatic place to look for shared libs;
this works on every other platform I build on except for QNX (both intel
and PPC). It's documented to work but it doesn't (QNX 6.1.0A).
This was broken in 6.1 - it has been fixed in 6.2
I still can't get the remote debugger to work with my shared libraries
on PPC; I've had to switch back to static libraries.
Here's some tips

Set the LD_LIBRARY_PATH required for your app before starting pdebug.

In gdb, set the solib-search-path variable to be a colon separated list
of paths pointing to the host side location of your shared libraries.

Once your shared libraries are in memory, you can view them with
'info sharedlibrary', and load the symbols with 'sharedlibrary'

Note that gdb cannot load them symbol information about shared libraries
before they are loaded into memory by the application, and that the
shared libraries should have a SONAME set (with the -Wl,--soname=name
option)

I hope this helps,

Colin

--
cburgess@qnx.com

Chris McKillop

Re: Devel tools for PPC?

Post by Chris McKillop » Thu Apr 04, 2002 10:33 pm

Paul D. Smith <pausmith@nortelnetworks.com> wrote:
I have to say I'm pretty bummed with QSSI's support of PPC so far. I
can't believe they don't even have a native debugger.
hey Paul! Sorry you are having such a hard time of it. Right now I don't
belive that we have "native" versions of gdb on anything except x86 since
we only support doing development on QNX on the x86 variant. Perhaps that
is an oversite on our part, but that is the reasoning behind it.
There's a bug in the gawk that they ship: it will not run unless you set
LD_LIBRARY_PATH to /lib. If you don't it fails with an error about
/lib/libm.so.2 not found (but it's right there!) I even tried using the
cross-compiler to build my own gawk and it has the identical problem.

I can't use -rpath to set an automatic place to look for shared libs;
this works on every other platform I build on except for QNX (both intel
and PPC). It's documented to work but it doesn't (QNX 6.1.0A).
I belive the people working on XFree86 for QNX have also pointed out this
problem and that it has been corrected internally. If and when this will
show up in a release is not my domain so I won't even bother to try to
comment. ;) If this isn't the problem the XFree guys have seen I am
sure Colin will speak up.
I still can't get the remote debugger to work with my shared libraries
on PPC; I've had to switch back to static libraries.
I am gonna try this out here on my PPC target and see if I have the same
problems. Just so I am clear - you are trying to debug shared libs that
you link with and not ones that you are manually dlopen()ing right? What
OS are you building and debugging from?

thanks,
chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Paul D. Smith

Re: Devel tools for PPC?

Post by Paul D. Smith » Fri Apr 05, 2002 2:14 am

%% Colin Burgess <cburgess@qnx.com> writes:

cb> Paul D. Smith <pausmith@nortelnetworks.com> wrote:
I have to say I'm pretty bummed with QSSI's support of PPC so far. I
can't believe they don't even have a native debugger.
cb> Right now we only support a native development environment on our
cb> x86 platform. However, we do make the source code to our GNU
cb> tools available for download if you wish to do your own thing with
cb> it (see developers.qnx.com)

I don't really care about a complete development environment; I probably
wouldn't want to build code on my embedded system anyway. But to me, a
native GDB is really critical! I can't run my code on an x86 to debug
it; my hardware is a custom embedded system.

Remote GDB is only a marginal substitute, especially when getting it
going and using it is as labor-intensive as this is!

Personally I think it's really not too much to ask that there be a
native debugger for a supposedly supported platform. And, it's not like
you need to write it from scratch: you are using GDB, which you've
already ported to QNX (on Intel), and which already runs on many other
OSs on PowerPC... how hard could it be for an engineer at QSSI who knows
this stuff to get a port to QNX on PowerPC?

I also need a make (because our unit test suite, which must run natively
of course) is driven with make. But, I already ported GNU make to QNX
PPC using the Solaris cross-compiler so that's OK.

And I'd really like a bash--the shell on the PPC is just different
enough to make me nuts.
There's a bug in the gawk that they ship: it will not run unless you set
LD_LIBRARY_PATH to /lib. If you don't it fails with an error about
/lib/libm.so.2 not found (but it's right there!) I even tried using the
cross-compiler to build my own gawk and it has the identical problem.
cb> What do you have LD_LIBRARY_PATH set to when it fails?

Nothing, it's not set at all:

No home directory.
Logging in with home = "/".
sh: /etc/profile[23]: tty: not found
Sun Jan 25 04:20:34 1970 on
Welcome to the QNX Realtime Platform!!
Last login: Sat Jan 24 23:12:07 1970 on
$ echo $LD_LIBRARY_PATH

$ /usr/bin/gawk
Could not find library libm.so.2

$ printf "%2.5f\n" 0.034
0.03400

$ export LD_LIBRARY_PATH=/lib

$ /usr/bin/gawk --version
GNU Awk 3.0.6
Copyright (C) 1989, 1991-2000 Free Software Foundation.
...
I can't use -rpath to set an automatic place to look for shared libs;
this works on every other platform I build on except for QNX (both intel
and PPC). It's documented to work but it doesn't (QNX 6.1.0A).
cb> This was broken in 6.1 - it has been fixed in 6.2

This is a pretty serious problem: any chance we can get a patch or some
kind of fix for this in 6.1?
I still can't get the remote debugger to work with my shared libraries
on PPC; I've had to switch back to static libraries.
cb> Here's some tips

cb> Set the LD_LIBRARY_PATH required for your app before starting pdebug.

I do this. I tried using the documented "set qnx..." in GDB methods for
handling environment variables, but all combinations of this failed as
well.

cb> Note that gdb cannot load them symbol information about shared libraries
cb> before they are loaded into memory by the application,

I'm setting a breakpoint at a symbol in the shared lib, then when the
breakpoint is hit I get an error from gdb saying it can't find my shared
library. If I try to step or continue I get a SIGILL.

Once I hit a breakpoint, the shared lib should be loaded...?

Also, if I'm in main() and I come to a function call that's in a shared
lib, even if I "s"tep it runs the entire function call as if I'd hit
"n"ext rather than stepping into the function.

cb> and that the shared libraries should have a SONAME set (with the
cb> -Wl,--soname=name option)

I definitely do this, on all my platforms:

[...]

qcc -V gcc_ntoppcbe -g -O2 -Wall -Werror -fPIC [...] -o ../../_rmc_QNX_6.1.0_ppcbe/src/cunit/example_test.o -c example_test.c

qcc -V gcc_ntoppcbe -shared -Wl,-soname,libcunit.so.1 -o ../../_rmc_QNX_6.1.0_ppcbe/lib/libcunit.so.1.0.0 [... .o's ...]

ln -s libcunit.so.1.0.0 ../../_rmc_QNX_6.1.0_ppcbe/lib/libcunit.so.1

ln -s libcunit.so.1.0.0 ../../_rmc_QNX_6.1.0_ppcbe/lib/libcunit.so

qcc -V gcc_ntoppcbe -Wl,-rpath,/.../_rmc_QNX_6.1.0_ppcbe/lib -o ../../_rmc_QNX_6.1.0_ppcbe/bin/example ... -L/.../_rmc_QNX_6.1.0_ppcbe/lib -lcunit -lsocket

cb> In gdb, set the solib-search-path variable to be a colon separated
cb> list of paths pointing to the host side location of your shared
cb> libraries.

Hm. This isn't in the docs. I'll try it...

OK, setting this variable works a lot better. I don't get the "can't
find libfoo.so" error any more. Shared library symbols are still not
loaded for me when the shared library is loaded, as they are on the
other platforms on which I use GDB.

cb> Once your shared libraries are in memory, you can view them with
cb> 'info sharedlibrary', and load the symbols with 'sharedlibrary'

Ouch. It's a pain that you have to do this by hand. But doing it this
way does work... somewhat.

Also, whenever I re-run the program it disables all my breakpoints and I
have to use "enable" to re-enable them. Again, this is very different
than the other platforms GDB runs on.

Also, the process is kind of dodgy still. Watch:

(gdb) target qnx pair4:8000
Remote debugging using pair4:8000

(gdb) set solib-search-path /.../_rmc_QNX_6.1.0_ppcbe/lib:/lib:/usr/lib

(gdb) run
Starting program: /.../_rmc_QNX_6.1.0_ppcbe/bin/example

Set a breakpoint in a shared library:

(gdb) br cUnit_register_test
Breakpoint 1 at 0x48041c5c

(gdb) c
Continuing.

Breakpoint 1, 0x48041c5c in cUnit_register_test ()

Good, we stopped. Now we look around, and realize no symbols are lodaded:

(gdb) bt
#0 0x48041c5c in cUnit_register_test ()
#1 0x48040898 in register_tests () at example_test.c:132
#2 0xfe365130 in ?? ()
from /.../_rmc_QNX_6.1.0_ppcbe/lib/libcunit.so.1

OK, let's load the symbols:

(gdb) info share
From To Syms Read Shared Object Library
0xfe363000 0xfe3679d0 No /.../_rmc_QNX_6.1.0_ppcbe/lib/libcunit.so.1
0xfe368000 0xfe380ccc No /lib/libsocket.so
0xfe300000 0xfe3bd848 No /lib/libc.so

(gdb) share /.../_rmc_QNX_6.1.0_ppcbe/lib/libcunit.so.1
Reading symbols from /.../_rmc_QNX_6.1.0_ppcbe/lib/libcunit.so.1...done.
Breakpoint 1 at 0xfe364684: file cUnit.c, line 155.

Fine. Let's go on...

(gdb) s

Program received signal SIGILL, Illegal instruction.
0x48041c5c in cUnit_register_test () at cUnit.c:151
151 {

Gack! I've tried loading the shared library symbols in other orders as
well, but so far the only thing that seems to work is to set a
breakpoint on main() and after it stops there I can load the symbol
table stuff.

(gdb) n

Program exited normally.

Ugh. And it didn't really exit normally, it stopped at the SIGILL. OK,
well, let's try running it again:

(gdb) run
Starting program:
/.../_rmc_QNX_6.1.0_ppcbe/bin/example

(gdb) c
Continuing.
warning: Cannot insert breakpoint 1:
warning: Temporarily disabling shared library breakpoints:
warning: breakpoint #1
cUnit: 2 tests of 2 passed.

Program exited normally.

Well, no SIGILL but it disabled my breakpoints!! I have to set a
breakpoint on main() so it stops at the beginning and I can re-enable my
shared library breakpoints. Phooey.

--
-------------------------------------------------------------------------------
Paul D. Smith <pausmith@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.

Paul D. Smith

Re: Devel tools for PPC?

Post by Paul D. Smith » Fri Apr 05, 2002 2:23 am

%% Chris McKillop <cdm@qnx.com> writes:

cm> Right now I don't belive that we have "native" versions of gdb on
cm> anything except x86 since we only support doing development on QNX
cm> on the x86 variant. Perhaps that is an oversite on our part, but
cm> that is the reasoning behind it.

Well, define "development"... I can't debug my code on an x86! It's an
embedded system for a proprietary board using PPC CPUs! My code
accesses hardware, etc. etc. It won't run on other platforms.

As I said to Colin, I can understand not providing a full development
environment (compiler, binutils, etc.) for PPC (sort of--although really
how much harder would it be to do it? All the tools you're using are
open source and already run on QNX (on Intel) and on PowerPC (with Linux
and other OSs)... doesn't seem like a lot of work for you to support
these natively)

But, a native debugger...?!?! That seems like an obvious "must have"
for a supported platform. Maybe it's just me :).
I still can't get the remote debugger to work with my shared libraries
on PPC; I've had to switch back to static libraries.
cm> I am gonna try this out here on my PPC target and see if I have
cm> the same problems. Just so I am clear - you are trying to debug
cm> shared libs that you link with and not ones that you are manually
cm> dlopen()ing right?

Yes.

cm> What OS are you building and debugging from?

Solaris. The PPC is a Sandpoint (right now; waiting for our QNX port to
the real hardware).

Colin's suggestion of setting the solib-search-path GDB variable seems
to have done the trick, although the tool is still really dodgy and
difficult to use.

It would be nice if that showed up in the docs at some point...

--
-------------------------------------------------------------------------------
Paul D. Smith <pausmith@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.

Chris McKillop

Re: Devel tools for PPC?

Post by Chris McKillop » Fri Apr 05, 2002 6:21 am

But, a native debugger...?!?! That seems like an obvious "must have"
for a supported platform. Maybe it's just me :).
There is a native debugger - pdebug. There just isn't a native front end to
pdebug. But that is splitting hairs. ;)

cm> What OS are you building and debugging from?

Solaris. The PPC is a Sandpoint (right now; waiting for our QNX port to
the real hardware).

Colin's suggestion of setting the solib-search-path GDB variable seems
to have done the trick, although the tool is still really dodgy and
difficult to use.

It would be nice if that showed up in the docs at some point...
Excellent. I will give this a spin on my Solaris setup. I will be targetting
an MTX board since that is my PPC target. I will also, unfortunatly, be
using our current 6.2 toolset. Has anyone on your team signed up for
the 6.2 testdrive? Best time to give feedback on issues is before it is
released. ;)

Just so you know (from reading your reply to colin), you can have a ~/.gdbrc
and it will "run" those commands on each startup. So if you have a common
set of setup commands you can put them in that file for faster debugging.

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Paul D. Smith

Re: Devel tools for PPC?

Post by Paul D. Smith » Fri Apr 05, 2002 2:16 pm

%% Chris McKillop <cdm@qnx.com> writes:
But, a native debugger...?!?! That seems like an obvious "must have"
for a supported platform. Maybe it's just me :).
cm> There is a native debugger - pdebug. There just isn't a native
cm> front end to pdebug. But that is splitting hairs. ;)

If pdebug is the "hard" part of getting the debugger going and the rest
is just "front end", then there is even _less_ reason to not provide it
(I fully confess I don't know the division of labor between pdebug and
gdb). Shouldn't take more than a day or so to compile it up, right?

But, maybe this is also splitting hairs ;).

cm> Excellent. I will give this a spin on my Solaris setup. I will
cm> be targetting an MTX board since that is my PPC target. I will
cm> also, unfortunatly, be using our current 6.2 toolset. Has anyone
cm> on your team signed up for the 6.2 testdrive? Best time to give
cm> feedback on issues is before it is released. ;)

Perhaps, but we barely have time to get our work done right now on a
stable (...) platform. Maybe after we make our proof-of-concept
milestone and get "official project" status we'll have more resources to
investigate 6.2. If we don't make that this entire conversation may
well be moot, and we'll be stuck with VxWorks for the foreseeable future :(.

cm> Just so you know (from reading your reply to colin), you can have
cm> a ~/.gdbrc and it will "run" those commands on each startup. So
cm> if you have a common set of setup commands you can put them in
cm> that file for faster debugging.

Yes, I know; the problem is that we are using ClearCase on Solaris and
using exported views. So, the pathname to the shared libraries is
different for every workspace of every user (NFS mounted), and most
users have multiple workspaces. This makes it unreasonable to put
commands setting so paths into ~/.gdbinit.

However, there are a _lot_ of tricks you can play with GDB (I've been
using GDB for almost 14 years :). For example you can use the -x option
to tell GDB to source a file of commands. I do this via a shell script
so I can run:

$ ./foo -x blaz bar baz biz
Core dumped.

$ agdb ./foo -x blaz bar baz biz

and have those arguments treated correctly. You can also use hook and
hookpost to invoke various operations when certain GDB commands are
run.

So, once I actually figure out the dynamics surrounding this I might be
able to fix it up through some script magic, but no amount of fixup will
overcome all the painful parts; for example that I need to set
LD_LIBRARY_PATH to a variable value before I start pdebug on the target
every time, etc.

--
-------------------------------------------------------------------------------
Paul D. Smith <pausmith@nortelnetworks.com> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.

Mario Charest

Re: Devel tools for PPC?

Post by Mario Charest » Fri Apr 05, 2002 6:55 pm

Shouldn't take more than a day or so to compile it up, right?
If you add up all the request people are making that only takes
a day or so to do I'd guess QSSL is 1.5 years, behind ;-)

- Mario

Chris McKillop

Re: Devel tools for PPC?

Post by Chris McKillop » Fri Apr 05, 2002 8:11 pm

If pdebug is the "hard" part of getting the debugger going and the rest
is just "front end", then there is even _less_ reason to not provide it
(I fully confess I don't know the division of labor between pdebug and
gdb). Shouldn't take more than a day or so to compile it up, right?

But, maybe this is also splitting hairs ;).
touche! ;)
Perhaps, but we barely have time to get our work done right now on a
stable (...) platform. Maybe after we make our proof-of-concept
milestone and get "official project" status we'll have more resources to
investigate 6.2. If we don't make that this entire conversation may
well be moot, and we'll be stuck with VxWorks for the foreseeable future :(.
Can you disclose (even by email) what that milestone date is?
So, once I actually figure out the dynamics surrounding this I might be
able to fix it up through some script magic, but no amount of fixup will
overcome all the painful parts; for example that I need to set
LD_LIBRARY_PATH to a variable value before I start pdebug on the target
every time, etc.
Why not just set LD_LIBRARY_PATH in the boot image so it is global? ie:


[virtual=ppcbe,raw] .bootstrap = {
startup-mtx600 -v
LD_LIBRARY_PATH=/proc/boot:/lib:/usr/lib PATH=/proc/boot procnto-600 -vv
}


chris


--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Igor Kovalenko

Re: Devel tools for PPC?

Post by Igor Kovalenko » Sat Apr 06, 2002 5:26 am

"Paul D. Smith" <pausmith@nortelnetworks.com> wrote in message
news:p5adsi51el.fsf@lemming.engeast.baynetworks.com...
%% Chris McKillop <cdm@qnx.com> writes:


But, a native debugger...?!?! That seems like an obvious "must have"
for a supported platform. Maybe it's just me :).
Not just you. We ended up always including debugger on targets. It is handy.

-- igor

Colin Burgess

Re: Devel tools for PPC?

Post by Colin Burgess » Sun Apr 07, 2002 10:05 pm

WRT auto loading of shared libs, you can set the gdb auto-solib-add variable
which will load the symbols of shared libs when they are mapped in.

These commands are documented, although in a somewhat peculiar place

Using GDB/Examining Source Files/Shared Libraries

Shared libraries

You can use the following commands when working with shared libraries:

sharedlibrary [regexp]
Load shared object library symbols for files matching the given regular
expression, regexp. If regexp is omitted, GDB tries to load symbols for
all loaded shared libraries.
info sharedlibrary
Display the status of the loaded shared object libraries.


The following parameters apply to shared libraries:

set solib-search-path dir[:dir...]
Set the search path for loading shared library symbols files that don't
have an absolute path. This path overrides the PATH and LD_LIBRARY_PATH
environment variables.

The default value is:

${QNX_TARGET}/${PROCESSOR}/lib:${QNX_TARGET}/${PROCESSOR}/dll


set solib-absolute-prefix prefix
Set the prefix for loading absolute shared library symbol files.
set auto-solib-add value
Make the loading of shared library symbols automatic or manual:
o If value is nonzero, symbols from all shared object libraries are loaded
automatically when the inferior process (i.e. the one being debugged)
begins execution, or when the dynamic linker informs GDB that a new
library has been loaded.
o If value is zero, symbols must be loaded manually with the sharedlibrary
command.


You can query the settings of these parameters with the show
solib-search-path, show solib-absolute-prefix, and show auto-solib-add
commands.

--
cburgess@qnx.com

Post Reply

Return to “qdn.public.qnxrtp.powerpc”