jbh@bnrunix.uucp (John B. Hampton) (06/02/89)
At BNR we have a "cross reference" facility for a proprietary language that,
among other things, will produce sizes of data items, offsets from
module-local "0", and running totals thereof. I would appreciate knowing
of a similar xref for the C language. Criteria are:
o Need source for the xref itself in C or executables runnable on
Sun 4 and HP 9000/300.
o The sizes and offsets should appear within a "normal" (cxref-
type) cross reference listing along with other info.
o Would be nice to have running totals in a listing beside the
pertinent data items.
Thanks in advance.
--
John Hampton (rti!bnrunix!jbh), 919-991-8146
BNR, Inc. POB 13478 RTP, NC 27709
[I suppose you could try to munge together the output of cxref and an "nm"
of the compiled version, but it'd be an interesting challenge. -John]
--
Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU
Plausible paths are { decvax | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requestmmengel@cuuxb.ATT.COM (Marc W. Mengel) (06/03/89)
In article <4007@ima.ima.isc.com> jbh@bnrunix.uucp (John B. Hampton) writes: > ... I would appreciate knowing of a similar xref for the C language... > o Need source for the xref itself in C or executables runnable on > Sun 4 and HP 9000/300. > o The sizes and offsets should appear within a "normal" (cxref- > type) cross reference listing along with other info. > o Would be nice to have running totals in a listing beside the > pertinent data items. If you compile a program with the -g option, and run "nm" on it, you will get a raw listing of the base information you want here; piping the output to "awk" and "sort" should make a pretty listing in the format you want. (i.e. to compute running totals and/or group local variable names with their enclosing function's name, etc. >John Hampton (rti!bnrunix!jbh), 919-991-8146 -- Marc Mengel mmengel@cuuxb.att.com attmail!mmengel ...!{lll-crg|att}!cuuxb!mmengel [If anybody actually does this, please let me know. -John] -- Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU Plausible paths are { decvax | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request
bph@buengc.BU.EDU (Blair P. Houghton) (06/05/89)
In article <4020@ima.ima.isc.com> mmengel@cuuxb.ATT.COM (Marc W. Mengel) writes: >> ... I would appreciate knowing of a similar xref for the C language... > > If you compile a program with the -g option, and run "nm" on > it, you will get a raw listing of the base information you Yes, but... Why does it list the functions I declared to "return" void as being type int()? My guess is that it's probably because our nm(1) (Encore Multimax; Umax) is older than its cc(1), but I think it might also have something to do with nm's assumptions about what is actually in the object-file, and there might be something missing (like a tag that would disambiguate the type of a function declared either void() or int()) from the object file. Anyone got a little more insight on this? --Blair "No doubt you are all thinking 'no doubt about it'; but, no flame could surprise me, educate me, or be of any other value to me or the rest of the world, so why would you bother? Answer the question and we can all get home in time to kiss the kids goodnight."
chris@mimsy.UUCP (Chris Torek) (06/05/89)
In article <3019@buengc.BU.EDU> bph@buengc.BU.EDU (Blair P. Houghton) writes: >Why does [nm -g] list the functions I declared to "return" void as being >type int()? ... I think it might also have something to do with nm's >assumptions about what is actually in the object-file, and there >might be something missing (like a tag that would disambiguate the type >of a function declared either void() or int()) from the object file. This last guess is the right answer. On the Encore, the C compiler emits old-style `.stabs' directives, and does not distingish between functions returning void and those returning int (since it is not in fact necessary to tell them apart at the machine level). (This is only one of many things about the Encore that needs modernising, the most serious being, in our view, the kernel netinet code....) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris