Devel tools for PPC?

QNX Newsgroups (Archives) qdn.public.qnxrtp.powerpc
1

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.

2

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.

3

%% “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.

4

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.

5

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.

6

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

7

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. :wink: 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/

8

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

9

%% 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 :slight_smile:.

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.

10

But, a native debugger…!!! That seems like an obvious “must have”
for a supported platform. Maybe it’s just me > :slight_smile:> .

There is a native debugger - pdebug. There just isn’t a native front end to
pdebug. But that is splitting hairs. :wink:


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. :wink:

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/

11

%% 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 > :slight_smile:> .

cm> There is a native debugger - pdebug. There just isn’t a native
cm> front end to pdebug. But that is splitting hairs. :wink:

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 :wink:.

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. :wink:

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 :frowning:.

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 :slight_smile:. 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.

12

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 :wink:

  • Mario
13

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 > :wink:> .

touche! :wink:

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 > :frowning:> .

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/

14

“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 > :slight_smile:> .

Not just you. We ended up always including debugger on targets. It is handy.

– igor

15

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

16

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

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

Hmm. I’ll try this. Thanks for the note.

Why is this all necessary here, when it’s not necessary anywhere else
(I’ve been using GDB for over 10 years on many different types of
systems–maybe that’s part of my problem; I know how it’s supposed to
work after all that time using it :slight_smile:). I don’t understand why the
default behavior of ntoppc-gdb is so different…?

cb> These commands are documented, although in a somewhat peculiar place

cb> set auto-solib-add value

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

Hmm. I saw this variable, but your documentation is not the same as
mine. Mine is for GDB 5.1.1; has this changed since 5.0? Here is what
mine says:

On HP-UX systems, GDB detects the loading of a shared library and
automatically reads in symbols from the newly loaded library, up to a
threshold that is initially set but that you can modify if you wish.

Beyond that threshold, symbols from shared libraries must be
explicitly loaded. To load these symbols, use the command
`sharedlibrary FILENAME’. The base address of the shared library is
determined automatically by GDB and need not be specified.

To display or set the threshold, use the commands:

set auto-solib-add THRESHOLD' Set the autoloading size threshold, in megabytes. If THRESHOLD is nonzero, symbols from all shared object libraries will be loaded automatically when the inferior begins execution or when the dynamic linker informs GDB that a new library has been loaded, until the symbol table of the program and libraries exceeds this threshold. Otherwise, symbols must be loaded manually, using the sharedlibrary’ command. The default threshold is 100 megabytes.

First note it sounds like this is only relevant on HP-UX (although maybe
it’s just not written clearly), and second note that it says the
default threshold is 100 M… which is more than enough. So I didn’t
go much further with this. But, now that I run “show auto-solib-add” in
ntoppc-gdb I can see that the value is 0. Was the default value was
modified between 5.0 and 5.1.1?

Hm. I just invoked my copy of GDB 5.0 I built for native Solaris and I
see this:

(gdb) show auto-solib-add
Autoloading of shared library symbols is 1.

Obviously the exact meaning of this variable has been changed between
5.0 and 5.1.1, from a true/false to a size value. But, it seems like
the GDB 5.0 that you provide is using different default values for these
settings than the ones that other targets use? Or does it always build
that way for cross compilers, or for PPC, or something?

–

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.

17

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

cm> Can you disclose (even by email) what that milestone date is?

Not exactly (don’t know myself, because until it’s official we can have
individuals pulled off for “priority interrupts”, which pushes out the
schedule–everyone understands that), but it’s very soon (like weeks).

cm> Why not just set LD_LIBRARY_PATH in the boot image so it is
cm> global? ie:

Maybe we’ll do this for the final system, but (a) we don’t have a
special boot image, and (b) we’re using many different paths; the shared
libraries are left in workspaces which are NFS-mounted to the target.
So, every workspace has a different path. Setting this in a boot image
is not feasible for our development environment.

–

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.

18

Why is this all necessary here, when it’s not necessary anywhere else
(I’ve been using GDB for over 10 years on many different types of
systems–maybe that’s part of my problem; I know how it’s supposed to
work after all that time using it > :slight_smile:> ). I don’t understand why the
default behavior of ntoppc-gdb is so different…?

What platforms were you using?

The handling of shared libs was ported directly from the svr4 shared lib
code. As such the behaviour is the same, although some of the defaults
are different (for example, automatic loading of shared library symbols).


Hmm. I saw this variable, but your documentation is not the same as
mine. Mine is for GDB 5.1.1; has this changed since 5.0? Here is what
mine says:

Yes, the limit was added after 5.0. In fact, this was the reason for
setting the default to non-automatic - it was exhausting the memory of
our RTP dev systems.

–
cburgess@qnx.com

19

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

cb> What platforms were you using?

I’ve used gdb on DG/UX, SunOS, Solaris, HP-UX, AIX, Ultrix, UnixWare,
FreeBSD, NetBSD, Linux, Irix, OSF/1, and maybe a few other oddball
systems I can’t recall right now :slight_smile:.

cb> Yes, the limit was added after 5.0. In fact, this was the reason
cb> for setting the default to non-automatic - it was exhausting the
cb> memory of our RTP dev systems.

Ah. OK. I think these kinds of things deserve some special mention in
the QNX docs, though, especially where you’ve changed the default
behavior of GDB.

Thanks for all your help… I’ll be sure to let you know if we run
into more problems :wink:.

–

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.

20

As a “thanks” for all the help, here is a little shell script which you
can use to invoke GDB for a remote target, that will set up properly for
shared library support. I’ve excised our code for determining what the
valid path for the shared libs is, since it’s obviously very specific to
your environment.

This is still problematic because there’s no way to script the
invocation of the pdebug properly on the target side, and I’d still
really like a native debugger. But, it’s better than typing all this by
hand…

#!/bin/sh

Invoke GDB to target QNX on the PPC, with setup.

Author:

Paul D. Smith <pausmith@nortelnetworks.com>

This file is in the public domain.

usage () {
cat <<EOF

usage: $0 : […args…]

Where:
is the hostname of the target system
is the port number where the pdebug server is listening
is the executable to debug (if it’s not in the current directory,
the script will try to find it in common locations).

Any remaining arguments are given to the executable when it’s invoked.

EOF
exit 1
}

Grab any GDB options. If you want to be very accurate about this you

need to do better (especially with option arguments).

opts=
while true; do
case “$1” in
–) shift; break ;;

-*) opts="$opts $1"; shift ;;

*) break ;;
esac
done

Do we have anything left? We need at least two arguments

case “$2” in
‘’) usage ;;
esac

target="$1"
program="$2"
shift 2

Compute SOLIBDIR … I just left it hardcoded for this example

SOLIBDIR=/usr/local/lib

If we don’t have $QNX_HOST, assume the default

The user can set PPCGDB to choose a different debugger.

PPCGDB=${PPCGDB:-${QNX_HOST:-/opt/QNXsdk/solaris/sparc}/usr/bin/ntoppc-gdb}

\

We will create a temporary script to be given to GDB as an initializer

script=${TMPDIR:-/tmp}/gdb$$

trap “rm $script” 0
trap “exit 1” 1 2 15

Create the initial setup script

In order to make things work correctly on the remote host with shared

libraries we have to set solib-search-path properly. Then before we

can set breakpoints, etc. in shared libraries we have to load their

symbols; mark that to happen automatically

Note that using quoted arguments is somewhat problematic here.

cat > $script <<EOF
shell rm $script
target qnx $target
set solib-search-path $SOLIBDIR:/lib:/usr/lib
set auto-solib-add 100
set args $@
EOF

Run it!!

exec $PPCGDB $opts -r -x $script – “$program”

\

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.