This is a multi-part message in MIME format.
--------------197BF1084914598F87BA2F7E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

When a compiler compiles code typically it prepends things to objects. There
now follows more then you ever really wanted to know about function names.

In 'c' the usual things is to prepend a single '_' - thus main becomes _main
and assert_wait becomes _assert_wait. Variables are not affected.

In c++ things become a little more complicated (for example if there were
multiple instances of a function add(int a, int b) and say add(float a,
float b) in class maths, and there was a static initalize addressing the
second one you would end up with something like _GLOBAL_$I$_maths_3addff,
and if it was the int one but not used globally _maths_3adddd (GLOBAL for an
initalized, $I$ for a constructor, $D$ for a destructor, _maths for the
class _ to separate the function, an integer for the length of the function
name, the function name, and then if multiple instances of the same function
exist, combinations of d (int), f (float), p (pointer) and v (void) for the
combination of arguments). Variables may have their class prepended (e.g.
_maths_foo)

[Note: on 1.2 machines and some 1.3a machines $I$ and $D$ were actually .I.
and .D. which is why early dynamic compiled libraries dont work with the
current release- well okay why MY libraries dont work with the current
release]

So you need to take those above rules into account when searching for where
a function is used/defined in the source.

Helpful Hint:

However, when searching for which object files define or use a symbol 'nm'
is a much better program. Say you were looking for the above function.
running nm on an object file may yeild:

       0x5a04    U    _assert_wait

This would mean the function is used, but not defined. However:

        0x5a04    T    _assert_wait

would tell you that is where it is defined. So a useful 'c' script in your
NetBSD kernel compile directory would be:

    foreach f ( *.o )
    echo ==$f==
    nm $f | grep $1    # if you were typing this at a command like enter
function name
    end

Using the above you could find out exactly where a function or variable is
used quick than with find over a tree.

No ideas on what the solution to your problem is though.:)

Paul

Tony Houghton wrote:

> In message <10fdf61748%tonyh@tonyh.tcp.co.uk>
>           Tony Houghton <tonyh@tcp.co.uk> wrote:
>
> > I tried to compile a kernel from ftp.netbsd.org and it failed to link:
> >
> > ld -Ttext F0000000 -e start -x -o netbsd ${SYSTEM_OBJ} vers.o
>
> [Snipped list of undefined symbols including _assert_wait]
>
> After not receiving the usual prompt help I get from asking things on
> this list I thought I'd try to get to the bottom of things myself so I
> had a look for one of the missing symbols:
>
> find /usr/src/sys -name '*.c' -exec grep _assert_wait {} \;
>
> It churned away, but instead of printing matches it just occasionally
> spewed out a mangled version of the above command and messages about
> find's syntax.
>
> [A little later]
>
> I decided to have another go and rebooted. Whether it was the reboot or
> deciding to give an option to grep (-l) I don't know, but the search
> started working (I used assert_wait without the leading _ this time to
> make sure it would find the one I knew was present).
>
> However, _assert_wait isn't mentioned anywhere in the code. The nearest
> it comes to being referred to in vm_fault.c is the macro
> PAGE_ASSERT_WAIT, but that expands to something including assert_wait
> without the leading _.
>
> assert_wait is used but apparently not defined. _assert_wait isn't
> referred to at all anywhere in the source or headers or Makefiles or any
> library headers. Is the linker adding the _ leading itself for some
> reason?
>
> --
>   \_________________
>                     \  http://homepages.tcp.co.uk/~tonyh/
>    The Curling Pages \ The home of WinEd, Bombz and NewsFind for RISC OS



--------------197BF1084914598F87BA2F7E
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Paul Wain
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Paul Wain
n:              Wain;Paul
org:            Network Computer Inc.
adr:            1000 Bridge Parkway;;;Redwood City;CA;94065;USA
email;internet: pwain@nc.com
title:          OS Development Engr.
tel;work:       +1 650 631 4628
tel;fax:        +1 650 631 4680
tel;home:       +1 415 297 6959 (Mobil)
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------197BF1084914598F87BA2F7E--