ObjDump

Is there an ObjDump type of utility for QNX4?

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:ajjmmm$q4f$1@inn.qnx.com

Is there an ObjDump type of utility for QNX4?

If you mean an object files disassembler then wdisasm works fine for this.
If you need to disassemble LMF files Ida Pro disassembler support this
format of executables.

// wbr

OK. Let me explain.

The Watcom linker is including a library module (from one of my libraries)
that it shouldn’t. Ordinarily this would only waste some memory. But in
this case the library module that is being erroneously included in the link
image has additional requirements that can not be satisfied from the
library. (It’s kind of looking for a callback function.) Therefore the
link fails.

I wanted to dump all of the object modules that come before the erroneously
included object module in the link image to see why it decided to include
that module.

So far what I’ve learned is that many of the C++ methods that are declared
as inline have instance names in the link map. I don’t know why. As far as
I can tell there should be no evidence of them in the link map, but there
is. They seem to be declared with a segment name (or type) of “Comdat:”. I
think that what the linker does with Comdat: segments is to merge all of
them with the same segment name into a single segment. I do understand
this. But I don’t understand why an inlined C++ method has an externally
visible name that shows up in the link map.


“Ian Zagorskih” <NOSPAM-ianzag@megasignal.com> wrote in message
news:ajogm4$8qa$1@inn.qnx.com

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:ajjmmm$q4f$> 1@inn.qnx.com> …
Is there an ObjDump type of utility for QNX4?



If you mean an object files disassembler then wdisasm works fine for this.
If you need to disassemble LMF files Ida Pro disassembler support this
format of executables.

// wbr

‘nm’ utility ?
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> schrieb im Newsbeitrag
news:ajjmmm$q4f$1@inn.qnx.com

Is there an ObjDump type of utility for QNX4?

Where do I get nm from?

“Peter Weber” <pw@dolphin.de> wrote in message
news:ajta2k$kcs$1@inn.qnx.com

‘nm’ utility ?
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > schrieb im Newsbeitrag
news:ajjmmm$q4f$> 1@inn.qnx.com> …
Is there an ObjDump type of utility for QNX4?
\

Uahhh, mine is from 6.Aug.1993, see attachment.

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> schrieb im Newsbeitrag
news:ajtr0s$2ot$1@inn.qnx.com

Where do I get nm from?

“Peter Weber” <> pw@dolphin.de> > wrote in message
news:ajta2k$kcs$> 1@inn.qnx.com> …
‘nm’ utility ?
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > schrieb im Newsbeitrag
news:ajjmmm$q4f$> 1@inn.qnx.com> …
Is there an ObjDump type of utility for QNX4?


\

OK. This helps. Two questions:

I tried use nm. Is there any additional docs on this utility?

Can it unmangle C++ names?

“Peter Weber” <pw@dolphin.de> wrote in message
news:ajttsf$4uc$1@inn.qnx.com

Uahhh, mine is from 6.Aug.1993, see attachment.

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > schrieb im Newsbeitrag
news:ajtr0s$2ot$> 1@inn.qnx.com> …
Where do I get nm from?

“Peter Weber” <> pw@dolphin.de> > wrote in message
news:ajta2k$kcs$> 1@inn.qnx.com> …
‘nm’ utility ?
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > schrieb im Newsbeitrag
news:ajjmmm$q4f$> 1@inn.qnx.com> …
Is there an ObjDump type of utility for QNX4?



\

Is the source to this utility available?

It SIGSEGV’s on several of my object files.

“Peter Weber” <pw@dolphin.de> wrote in message
news:ajttsf$4uc$1@inn.qnx.com

Uahhh, mine is from 6.Aug.1993, see attachment.

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > schrieb im Newsbeitrag
news:ajtr0s$2ot$> 1@inn.qnx.com> …
Where do I get nm from?

“Peter Weber” <> pw@dolphin.de> > wrote in message
news:ajta2k$kcs$> 1@inn.qnx.com> …
‘nm’ utility ?
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > schrieb im Newsbeitrag
news:ajjmmm$q4f$> 1@inn.qnx.com> …
Is there an ObjDump type of utility for QNX4?



\

I believe “inline” is just a suggestion to the compiler and the compiler is
allowed to ignore it. I also believe that it is possible to have both an
inline version and a non-inline version of the same function/method. I can’t
recall when this may occur though.

Try pointing your news server to news.openwatcom.org and asking there.


“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:ajrn1j$gpo$1@inn.qnx.com

OK. Let me explain.

The Watcom linker is including a library module (from one of my libraries)
that it shouldn’t. Ordinarily this would only waste some memory. But in
this case the library module that is being erroneously included in the
link
image has additional requirements that can not be satisfied from the
library. (It’s kind of looking for a callback function.) Therefore the
link fails.

I wanted to dump all of the object modules that come before the
erroneously
included object module in the link image to see why it decided to include
that module.

So far what I’ve learned is that many of the C++ methods that are declared
as inline have instance names in the link map. I don’t know why. As far
as
I can tell there should be no evidence of them in the link map, but there
is. They seem to be declared with a segment name (or type) of “Comdat:”.
I
think that what the linker does with Comdat: segments is to merge all of
them with the same segment name into a single segment. I do understand
this. But I don’t understand why an inlined C++ method has an externally
visible name that shows up in the link map.


“Ian Zagorskih” <> NOSPAM-ianzag@megasignal.com> > wrote in message
news:ajogm4$8qa$> 1@inn.qnx.com> …
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:ajjmmm$q4f$> 1@inn.qnx.com> …
Is there an ObjDump type of utility for QNX4?



If you mean an object files disassembler then wdisasm works fine for
this.
If you need to disassemble LMF files Ida Pro disassembler support this
format of executables.

// wbr

\

Bill, AFAIK it is from /usr/free, but don’t ask me what kind of package :wink:
I think unmangeling is not supported by this old nm, sorry.
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> schrieb im Newsbeitrag
news:aju0pc$71o$1@inn.qnx.com

Is the source to this utility available?
For me it works for C modules under 10.6…

sorry, no idea about source. May a QSSL rep. could answer this? Or
news://news.openwatcom.org provides some tools.

It SIGSEGV’s on several of my object files.
may it is too old for C++ objects?

-snip-

Yes, I found a newer nm in /usr/free that doesn’t SIGSEGV.

Still no docs or C++ support. I’ve started learning the name mangling that
C++ uses.

“Peter Weber” <pw@dolphin.de> wrote in message
news:ak05c6$nkm$1@inn.qnx.com

Bill, AFAIK it is from /usr/free, but don’t ask me what kind of package
:wink:
I think unmangeling is not supported by this old nm, sorry.
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > schrieb im Newsbeitrag
news:aju0pc$71o$> 1@inn.qnx.com> …
Is the source to this utility available?
For me it works for C modules under 10.6…
sorry, no idea about source. May a QSSL rep. could answer this? Or
news://news.openwatcom.org provides some tools.

It SIGSEGV’s on several of my object files.
may it is too old for C++ objects?
-snip-

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

OK. Let me explain.

The Watcom linker is including a library module (from one of my libraries)
that it shouldn’t. Ordinarily this would only waste some memory. But in
this case the library module that is being erroneously included in the link
image has additional requirements that can not be satisfied from the
library. (It’s kind of looking for a callback function.) Therefore the
link fails.

I wanted to dump all of the object modules that come before the erroneously
included object module in the link image to see why it decided to include
that module.

wlib has a symbol trace command… I think it is “symtrace”, might
need to be something like "op symtrace " that can tell
where it finds/found a particular symbol.

So far what I’ve learned is that many of the C++ methods that are declared
as inline have instance names in the link map. I don’t know why. As far as
I can tell there should be no evidence of them in the link map, but there
is. They seem to be declared with a segment name (or type) of “Comdat:”. I
think that what the linker does with Comdat: segments is to merge all of
them with the same segment name into a single segment. I do understand
this. But I don’t understand why an inlined C++ method has an externally
visible name that shows up in the link map.

Ooo… C++ that makes it messier…the symbol names are all going to
be mangled. Ugh.

-David


QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

By re-ordering the modules in my library I was able to circumvent my
problem. There are still things being linked into an executable that should
NOT be there. I don’t know why the linker is sucking them in.

So what I really have is a linker problem, not a library problem.

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:al38jl$alp$2@nntp.qnx.com

“Bill Caroselli (Q-TPS)” <> QTPS@earthlink.net> > wrote:
OK. Let me explain.

The Watcom linker is including a library module (from one of my
libraries)
that it shouldn’t. Ordinarily this would only waste some memory. But
in
this case the library module that is being erroneously included in the
link
image has additional requirements that can not be satisfied from the
library. (It’s kind of looking for a callback function.) Therefore the
link fails.

I wanted to dump all of the object modules that come before the
erroneously
included object module in the link image to see why it decided to
include
that module.

wlib has a symbol trace command… I think it is “symtrace”, might
need to be something like "op symtrace " that can tell
where it finds/found a particular symbol.

So far what I’ve learned is that many of the C++ methods that are
declared
as inline have instance names in the link map. I don’t know why. As
far as
I can tell there should be no evidence of them in the link map, but
there
is. They seem to be declared with a segment name (or type) of
“Comdat:”. I
think that what the linker does with Comdat: segments is to merge all of
them with the same segment name into a single segment. I do understand
this. But I don’t understand why an inlined C++ method has an
externally
visible name that shows up in the link map.

Ooo… C++ that makes it messier…the symbol names are all going to
be mangled. Ugh.

-David


QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.