Does QNX give the user a way to look up global symbols and then examine the
memory location associated with that symbol?
Thanks,
David Kuechenmeister
David Kuechenmeister wrote:
Thanks again for the suggestions; the dumper program is about the closest to
what I’d like to have. I don’t like to run programs in a debugger when
timing issues are being examined. The debugger will always add some
stochastic behavior, either good or bad, and I want to eliminate that.I guess what I have to do is put the “global” data in shared memory and then
write a utility to dump that.
There is a program called Stethoscope by some company whose name
escapes me right now. It sounds like this is what you want. I
had written a program like this for QNX4. It’s pretty easy to
write something like this that works for global variables (since
I personally never use global variables, it is a useless tool
for me).
You could write a tool like this that would be
“minimally invasive”, and allow access to data on the stack, but
that is much more complicated (it would need to keep track of
frames, and recognize when items were going in and out of
scope dynamically - since there would be no breakpoints). Also,
to get decent performance in real-time, it would need to be self
hosted (since it would require low latency in order to sample
sufficiently - tracking the stack frame etc.).
Since QNX6 is the only “real” self-hosted RTOS, it is the only
platform that even stands a chance of getting a (IMO, very
useful) tool like this.
David Kuechenmeister wrote:
It’s funny you would mention Stethoscope, unless you’re doing it
tongue-in-cheek. It’s a Wind River product and I’ve used it on modem
projects with great results.
The only tongue-in-cheek part, is the part about globals. I have
used stethoscope and found it to be useless because I have no
global variables in my code.
I find it odd that some company would write a tool that “requires”
users to violate one of the most basic tenets of s/w engineering
in order to use it.
I like the idea of a “stethoscope like” tool, but unless it can
track stack based data it borders on completely useless (at least
to those who actually practice s/w engineering principles 
.
There is another WRS product that is very nice
for looking at timing. It’s like a software bus analyzer and I just can’t
remember what it’s called. Windview, that’s it.
QNX has a directly comparable tool to Windview (part of the SAT I
believe).
Between those two programs,
there isn’t much you can’t find out about the state of the program.
Unless it happens to be state that’s kept on the stack (where it
should be
I wish we had some tool-writing time on this, or any other project. There
are some good ones that could be very beneficial to QNX developers.
The only tool that is missing is a “stethoscope like” tool with
stack symbol support. IMO, QNX will be the first platform to
have such a tool.
objdump ?
-xtang
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote in message
news:apjm4g$ejg$1@inn.qnx.com…
Does QNX give the user a way to look up global symbols and then examine
the
memory location associated with that symbol?Thanks,
David Kuechenmeister
nm gets me the address, too.
nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value of
m_workon?
Thanks,
“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:apjmhk$g6s$1@nntp.qnx.com…
objdump ?
-xtang
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote in message
news:apjm4g$ejg$> 1@inn.qnx.com> …
Does QNX give the user a way to look up global symbols and then examine
the
memory location associated with that symbol?Thanks,
David Kuechenmeister
\
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
nm gets me the address, too.
nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value of
m_workon?
gdb?
I’d rather not run these programs in a debugger. This is an embedded target
so I don’t have the gnu tools on the board. I had hoped that Neutrino had a
utility to dump memory.
Thanks for the suggestions.
“Colin Burgess” <cburgess@qnx.com> wrote in message
news:apjqcq$inn$1@nntp.qnx.com…
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
nm gets me the address, too.nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value of
m_workon?gdb?
Well, you can always use dumper to take a core file. dumper -p will take a snapshot without killing the process. If dumper is
saving the core file on something like a cifs or nfs directory, all you need
is:
[Terminal 1 telnetted to host]: dumper -p
[Terminal 2 in shared dir on host]: gdb my_prog my_prog.core
Examine memory to your hearts content.
cheers,
Kris
“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:apjvns$os7$1@inn.qnx.com…
I’d rather not run these programs in a debugger. This is an embedded
target
so I don’t have the gnu tools on the board. I had hoped that Neutrino had
a
utility to dump memory.Thanks for the suggestions.
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:apjqcq$inn$> 1@nntp.qnx.com> …
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
nm gets me the address, too.nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value of
m_workon?gdb?
pdebug on target and gdb on the host will work around that. Or qconn on the
target, and IDE on the host for the same effect.
The address you want to dump is only valid in the context of the process
(who owns that address) at the time it’s running. So unless you’re
debugging the process, how do you know what physical address you want to
see? The quick and dirty memory dump is to have the process dump the memory
itself when appropriate.
\
Cheers,
Adam
QNX Software Systems Ltd.
[ amallory@qnx.com ]
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote in message
news:apjvns$os7$1@inn.qnx.com…
I’d rather not run these programs in a debugger. This is an embedded
target
so I don’t have the gnu tools on the board. I had hoped that Neutrino had
a
utility to dump memory.Thanks for the suggestions.
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:apjqcq$inn$> 1@nntp.qnx.com> …
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
nm gets me the address, too.nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value of
m_workon?gdb?
“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:apjvns$os7$1@inn.qnx.com…
I’d rather not run these programs in a debugger. This is an embedded
target
so I don’t have the gnu tools on the board. I had hoped that Neutrino had
a
utility to dump memory.
You can look at physical memory with spatch /dev/mem, the problem is the
address 0x0805c264 is a virtual address. Going from virtual to physical
address ain’t easy.
Thanks for the suggestions.
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:apjqcq$inn$> 1@nntp.qnx.com> …
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
nm gets me the address, too.nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value of
m_workon?gdb?
Thanks again for the suggestions; the dumper program is about the closest to
what I’d like to have. I don’t like to run programs in a debugger when
timing issues are being examined. The debugger will always add some
stochastic behavior, either good or bad, and I want to eliminate that.
I guess what I have to do is put the “global” data in shared memory and then
write a utility to dump that.
“Mario Charest” postmaster@127.0.0.1 wrote in message
news:apk154$q9q$1@inn.qnx.com…
“David Kuechenmeister” <> david.kuechenmeister@viasat.com> > wrote in message
news:apjvns$os7$> 1@inn.qnx.com> …
I’d rather not run these programs in a debugger. This is an embedded
target
so I don’t have the gnu tools on the board. I had hoped that Neutrino
had
a
utility to dump memory.
You can look at physical memory with spatch /dev/mem, the problem is the
address 0x0805c264 is a virtual address. Going from virtual to physical
address ain’t easy.Thanks for the suggestions.
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:apjqcq$inn$> 1@nntp.qnx.com> …
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
nm gets me the address, too.nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value
of
m_workon?gdb?
–
cburgess@qnx.com
\
It’s funny you would mention Stethoscope, unless you’re doing it
tongue-in-cheek. It’s a Wind River product and I’ve used it on modem
projects with great results. There is another WRS product that is very nice
for looking at timing. It’s like a software bus analyzer and I just can’t
remember what it’s called. Windview, that’s it. Between those two programs,
there isn’t much you can’t find out about the state of the program.
I wish we had some tool-writing time on this, or any other project. There
are some good ones that could be very beneficial to QNX developers.
Thanks,
“Rennie Allen” <rallen@csical.com> wrote in message
news:3DBD2F3E.6040803@csical.com…
David Kuechenmeister wrote:
Thanks again for the suggestions; the dumper program is about the
closest to
what I’d like to have. I don’t like to run programs in a debugger when
timing issues are being examined. The debugger will always add some
stochastic behavior, either good or bad, and I want to eliminate that.I guess what I have to do is put the “global” data in shared memory and
then
write a utility to dump that.There is a program called Stethoscope by some company whose name
escapes me right now. It sounds like this is what you want. I
had written a program like this for QNX4. It’s pretty easy to
write something like this that works for global variables (since
I personally never use global variables, it is a useless tool
for me).You could write a tool like this that would be
“minimally invasive”, and allow access to data on the stack, but
that is much more complicated (it would need to keep track of
frames, and recognize when items were going in and out of
scope dynamically - since there would be no breakpoints). Also,
to get decent performance in real-time, it would need to be self
hosted (since it would require low latency in order to sample
sufficiently - tracking the stack frame etc.).Since QNX6 is the only “real” self-hosted RTOS, it is the only
platform that even stands a chance of getting a (IMO, very
useful) tool like this.
If you were to use ‘spatch /proc//as’ and then goto 0x<some_address>,
you would see that section of memory.
cheers,
Kris
“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:apk0ej$n7b$1@nntp.qnx.com…
Well, you can always use dumper to take a core file. dumper -p will take a snapshot without killing the process. If dumper is
saving the core file on something like a cifs or nfs directory, all you
need
is:[Terminal 1 telnetted to host]: dumper -p <pid
[Terminal 2 in shared dir on host]: gdb my_prog my_prog.coreExamine memory to your hearts content.
cheers,
Kris
“David Kuechenmeister” <> david.kuechenmeister@viasat.com> > wrote in message
news:apjvns$os7$> 1@inn.qnx.com> …
I’d rather not run these programs in a debugger. This is an embedded
target
so I don’t have the gnu tools on the board. I had hoped that Neutrino
had
a
utility to dump memory.Thanks for the suggestions.
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:apjqcq$inn$> 1@nntp.qnx.com> …
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
nm gets me the address, too.nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value
of
m_workon?gdb?
–
cburgess@qnx.com
\
pdebug and qnet work well also…attach pdebug to a pty and point gdb to the
corresponding tty…but you have to restart pdebug each time you quit gdb as
it gets a sighup…but I guess stty would fix that as well, yes?
Kevin
“Adam Mallory” <amallory@qnx.com> wrote in message
news:apk0h0$n7k$1@nntp.qnx.com…
pdebug on target and gdb on the host will work around that. Or qconn on
the
target, and IDE on the host for the same effect.The address you want to dump is only valid in the context of the process
(who owns that address) at the time it’s running. So unless you’re
debugging the process, how do you know what physical address you want to
see? The quick and dirty memory dump is to have the process dump the
memory
itself when appropriate.
\Cheers,
AdamQNX Software Systems Ltd.
[ > amallory@qnx.com > ]With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote in message
news:apjvns$os7$> 1@inn.qnx.com> …
I’d rather not run these programs in a debugger. This is an embedded
target
so I don’t have the gnu tools on the board. I had hoped that Neutrino
had
a
utility to dump memory.Thanks for the suggestions.
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:apjqcq$inn$> 1@nntp.qnx.com> …
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
nm gets me the address, too.nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value
of
m_workon?gdb?
–
cburgess@qnx.com
\
Thanks. I had tried using spatch, based on your earlier post, but I couldn’t
get the full screen part to work. The extra note that you provided was just
the ticket.
Thanks again,
drk
“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:apkbpk$1o1$1@nntp.qnx.com…
If you were to use ‘spatch /proc//as’ and then goto 0x<some_address>,
you would see that section of memory.cheers,
Kris
“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:apk0ej$n7b$> 1@nntp.qnx.com> …
Well, you can always use dumper to take a core file. dumper -p will take a snapshot without killing the process. If dumper is
saving the core file on something like a cifs or nfs directory, all you
need
is:[Terminal 1 telnetted to host]: dumper -p <pid
[Terminal 2 in shared dir on host]: gdb my_prog my_prog.coreExamine memory to your hearts content.
cheers,
Kris
“David Kuechenmeister” <> david.kuechenmeister@viasat.com> > wrote in
message
news:apjvns$os7$> 1@inn.qnx.com> …
I’d rather not run these programs in a debugger. This is an embedded
target
so I don’t have the gnu tools on the board. I had hoped that Neutrino
had
a
utility to dump memory.Thanks for the suggestions.
“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:apjqcq$inn$> 1@nntp.qnx.com> …
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
nm gets me the address, too.nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the
value
of
m_workon?gdb?
–
cburgess@qnx.com
\
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
nm gets me the address, too.
nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value of
m_workon?
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
char buf[5000];
int main( int argc, char **argv )
{
int fd;
int ret;
int off;
off = atoi(argv[2]);
fd = open( argv[1], O_RDONLY );
printf(“open returned %d, errno %d\n”, fd, errno );
ret = lseek( fd, off, SEEK_SET );
printf(“lseek returned %d, errno %d\n”, ret, errno );
ret = read(fd, buf, 2000);
printf(“read returned %d, errno %d\n”, ret, errno );
/* dump contents of buff here as appropriate */
}
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Universal Control Panel ? (look at the cafe!)
Colin Burgess a écrit:
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
nm gets me the address, too.
\nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value of
m_workon?
gdb?
Bill Caroselli (Q-TPS) wrote:
Is this something that is feasable?
Not on a PC (all you’d have a copy of is whatever pattern
the BIOS memory check wrote into the ram - if you did a
soft-boot that is - which might not even be possible).
Would anyone else be interested in this kind of feature?
How many times have you had a kernel crash with QNX ?
Not often, enough I suspect to warrant much in the way
of development.
I don’t understand. What is the Unversal Control Panel or cafe?
Thanks,
“Alain Bonnefoy” <alain.bonnefoy@icbt.com> wrote in message news:3DBFD1A3.7050806@icbt.com…
Universal Control Panel ? (look at the cafe!)
Colin Burgess a écrit:
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
nm gets me the address, too.
nm cmdProcessor.exe | grep m_workon
0805c264 D m_workon
How can I examine the memory at address 0x0805c264 to get the value of
m_workon?
gdb?
This has nothing to do with your question but it reminded me of something
that I asked about on QUICS long, long ago.
I used to work on an IBM Serias/1. It had a very interesting utility. It
was a 8" floppy that you could boot. It destroyed only like the first 2K or
RAM. Then what it did was copy all of the rest of RAM to the floppy. You
could then reboot the OS and run a second utility that would look at the
floppy and tell you all of the programs that were running when the system
died. You could examine the ready queues and you could even examine the
data of every program loaded.
I realize that systems have way too much memory to write to a floppy
anymore. But it would be very nice to be able to boot a partition, for
instance, that copied all of RAM to the rest of the partition. And then
have a second utility to go back and examine the corpse of the dead system.
I realize that this presents a security hole. But it would be extreamly
useful for debugging a dead system. It seams to me that the first utility
would actually be very easy to write. The second one that interpreted the
RAM dump would have to be OS and version aware (know where to find
process/thread lists and readys queues, etc. in the RAM dump).
Is this something that is feasable?
Would anyone else be interested in this kind of feature?
Quite frankly I think the people it would benefit the most is QSSL.