[PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot with Abatron BDI emulator an error occurs: .. (gdb) tar remote bdi:2001 Remote debugging using bdi:2001 0xeff80050 in ?? () (gdb) mon reset (gdb) cont Continuing. Warning: Cannot insert breakpoint -1. Error accessing memory address 0xc0000000: Unknown error 4294967295.

[PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot with Abatron BDI emulator an error occurs: .. (gdb) tar remote bdi:2001 Remote debugging using bdi:2001 0xeff80050 in ?? () (gdb) mon reset (gdb) cont Continuing. Warning: Cannot insert breakpoint -1. Error accessing memory address 0xc0000000: Unknown error 4294967295.

[Joakim Tjernlund]

    (gdb) maintenance info breakpoints
    Num     Type           Disp Enb Address    What
    -1      shlib events   keep y   0xc0000000 <_stext> inf 1

gdb mistakenly inserts a special shared library BP even though
there area no such libs in either linux or u-boot.
Fix by testing for ld.so presence.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 solib-svr4.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/solib-svr4.c b/solib-svr4.c
index 69d3cb5..d949005 100644
--- a/solib-svr4.c
+++ b/solib-svr4.c
@@ -1699,7 +1699,7 @@ enable_break (struct svr4_info *info, int from_tty)
 	}
     }
 
-  if (!current_inferior ()->attach_flag)
+  if (interp_name && !current_inferior ()->attach_flag)
     {
       for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++)
 	{
-- 
1.7.3.4

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Pedro Alves]

On 06/01/2012 04:01 PM, Joakim Tjernlund wrote:

> 
> gdb mistakenly inserts a special shared library BP even though
> there area no such libs in either linux or u-boot.
> Fix by testing for ld.so presence.


Thanks.  I've ran it through the testsuite just in case; no regressions.

Anyone know of any reason we shouldn't put this in?  I don't know the
history of these particular fallbacks, and don't know which hosts or
conditions might need them.  I've found this as further back as
around gdb-4.9 (1993), where we had:

/* On SVR4 systems, for the initial implementation, use some runtime startup
   symbol as the "startup mapping complete" breakpoint address.  The models
   for SunOS and SVR4 dynamic linking debugger support are different in that
   SunOS hits one breakpoint when all mapping is complete while using the SVR4
   debugger support takes two breakpoint hits for each file mapped, and
   there is no way to know when the "last" one is hit.  Both these
   mechanisms should be tied to a "breakpoint service routine" that
   gets automatically executed whenever one of the breakpoints indicating
   a change in mapping is hit.  This is a future enhancement.  (FIXME) */

#define BKPT_AT_SYMBOL 1

#if defined (BKPT_AT_SYMBOL) && defined (SVR4_SHARED_LIBS)
static char *bkpt_names[] = {
#ifdef SOLIB_BKPT_NAME
  SOLIB_BKPT_NAME,              /* Prefer configured name if it exists. */
#endif
  "_start",
  "main",
  NULL
};
#endif

and at that point solib.c was a mess used by both SVR4 and a.out SunOS.

(Incidentally, the present solib-sunos.c is only really used on a.out BSD
targets, not by Solaris.)

I've written a ChangeLog entry for you.  Please see the gdb/CONTRIBUTE
for the next time.  Thanks.

2012-06-01  Joakim Tjernlund  <Joakim.Tjernlund@transmode.se>

	* solib-svr4.c (enable_break): Don't fallback to setting the solib
	event breakpoint at _start, __start or main if a program
	interpreter is not found.
---

diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index bd0141a..307e483 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -1707,7 +1707,7 @@ enable_break (struct svr4_info *info, int from_tty)
 	}
     }

-  if (!current_inferior ()->attach_flag)
+  if (interp_name != NULL && !current_inferior ()->attach_flag)
     {
       for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++)
 	{

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Pedro Alves]

On 06/01/2012 06:22 PM, Jan Kratochvil wrote:

> On Fri, 01 Jun 2012 18:21:28 +0200, Pedro Alves wrote:
>> --- a/gdb/solib-svr4.c
>> +++ b/gdb/solib-svr4.c
>> @@ -1707,7 +1707,7 @@ enable_break (struct svr4_info *info, int from_tty)
>>  	}
>>      }
>>
>> -  if (!current_inferior ()->attach_flag)
>> +  if (interp_name != NULL && !current_inferior ()->attach_flag)
>>      {
>>        for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++)
>>  	{
> 
> It has a regression in the case below.
> 
> OTOH one has to strip _start to make it a regression as with _start GDB did not
> catch startup libraries even before.


Yeah, that's a really contrived example.  You're relying on stopping at main,
not when the DSO is really loaded (_dl_debug_state) to set the breakpoint.
I can see _start not existing, with the entry point named something else,
but if you strip your static binary to miss _dl_debug_state, you won't get
main either.  (and then static binaries that dlopen aren't something you'd
want to do normally.)

-- 
Pedro Alves

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Jan Kratochvil]

On Fri, 01 Jun 2012 18:21:28 +0200, Pedro Alves wrote:
> --- a/gdb/solib-svr4.c
> +++ b/gdb/solib-svr4.c
> @@ -1707,7 +1707,7 @@ enable_break (struct svr4_info *info, int from_tty)
>  	}
>      }
> 
> -  if (!current_inferior ()->attach_flag)
> +  if (interp_name != NULL && !current_inferior ()->attach_flag)
>      {
>        for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++)
>  	{

It has a regression in the case below.

OTOH one has to strip _start to make it a regression as with _start GDB did not
catch startup libraries even before.

This is why I suggested to omit only "__start" and "_start" but not "main" if
INTERP_NAME == NULL.

But maybe so broken systems are not so common nowadays to still care about
them.


Regards,
Jan


==> 53.C <==
#include <dlfcn.h>
#include <assert.h>
#include <stdio.h>
static void *lib;
class C {
public:
  C();
} c;
C::C() {
  lib = dlopen ("./53l.so", RTLD_NOW);
  assert(lib);
  puts("opened");
}
int main () {
  void (*fp)(void)=(void (*)(void))dlsym(lib,"l");
  assert(fp);
  fp();
}

==> 53l.C <==
#include <stdio.h>
class D {
public:
  D();
} d;
D::D() {
  puts ("in-library before-main");
}
extern "C" void l(void) {
  puts ("in-library after-main");
}

$ ./gdb-unpatched ./53 -ex 'set breakpoint pending on' -ex 'b l' -ex run 
Breakpoint 1, 0x00007ffff7dfd71e in l () from ./53l.so
(gdb) _

$ ./gdb-patched ./53 -ex 'set breakpoint pending on' -ex 'b l' -ex run 
[Inferior 1 (process 2188) exited normally]
(gdb) _

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Jan Kratochvil]

On Fri, 01 Jun 2012 19:37:22 +0200, Pedro Alves wrote:
> Yeah, that's a really contrived example.  You're relying on stopping at main,
> not when the DSO is really loaded (_dl_debug_state) to set the breakpoint.
> I can see _start not existing, with the entry point named something else,
> but if you strip your static binary to miss _dl_debug_state, you won't get
> main either.  (and then static binaries that dlopen aren't something you'd
> want to do normally.)

I do not have to strip the binary to not have _dl_debug_state, there are many
libc implementations out there and I guess they are not all compatible with
the "_dl_debug_state" naming.  I guess this is also the reason why GDB knows
so many names for it:
  "r_debug_state",
  "_r_debug_state",
  "_dl_debug_state",
  "rtld_db_dlactivity",
  "__dl_rtld_db_dlactivity",
  "_rtld_debug_state",

And the goal of this non-ld.so breakpoint is that most of programs loads
libraries only during its init, before main, therefore a breakpoint at "main"
should catch them all.

OTOH as I said current GDB will place the breakpoint to _start first and it
will miss those libraries anyway.  So it is not a regression.

Also nowadays some 3rd party runtime probably more adapts to GDB than vice
verse.


Regards,
Jan

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Jan Kratochvil]

On Fri, 01 Jun 2012 19:22:14 +0200, Jan Kratochvil wrote:
> OTOH one has to strip _start to make it a regression as with _start GDB did not
> catch startup libraries even before.

Forgot the reproducer compilation commandline:

C="$HOME/redhat/gcc47-static-root/bin/g++ -Wall";$C -o 53l.so 53l.C -shared -fPIC;$C -o 53 53.C -static -ldl;objcopy -N _dl_debug_state -N _start 53


Regards,
Jan

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Pedro Alves]

On 06/01/2012 06:45 PM, Jan Kratochvil wrote:

> On Fri, 01 Jun 2012 19:37:22 +0200, Pedro Alves wrote:
>> > Yeah, that's a really contrived example.  You're relying on stopping at main,
>> > not when the DSO is really loaded (_dl_debug_state) to set the breakpoint.
>> > I can see _start not existing, with the entry point named something else,
>> > but if you strip your static binary to miss _dl_debug_state, you won't get
>> > main either.  (and then static binaries that dlopen aren't something you'd
>> > want to do normally.)
> I do not have to strip the binary to not have _dl_debug_state, there are many
> libc implementations out there and I guess they are not all compatible with
> the "_dl_debug_state" naming.  


The fix for those would be to either list the name in GDB, or fix the
loaded to use the same name as GDB already knows.  I think the fallback must
be for something else.

> I guess this is also the reason why GDB knows
> so many names for it:
>   "r_debug_state",
>   "_r_debug_state",
>   "_dl_debug_state",
>   "rtld_db_dlactivity",
>   "__dl_rtld_db_dlactivity",
>   "_rtld_debug_state",


> And the goal of this non-ld.so breakpoint is that most of programs loads

> libraries only during its init, before main, therefore a breakpoint at "main"
> should catch them all.


Looking a bit more, I don't think that's the original motivation.
Instead, it looks more like the intent was to get to a point after the
interpreter has mapped in the program, and therefore it is safe to install
breakpoints in the main program.  See solib-sunos.c (and remember
that solib.c originally supported both svr4 and sunos):

   For SunOS executables, this first instruction is typically the
   one at "_start", or a similar text label, regardless of whether
   the executable is statically or dynamically linked.  The runtime
   startup code takes care of dynamically linking in any shared
   libraries, once gdb allows the inferior to continue.

So even for static binaries, you still need to place a breakpoint at
_start and run to it, in order to see the main program mapped in.
And since programs might choose a different entry point name,
"main" is chosen as fallback.

Looking even further back, to gdb 4.6, we see:

#else	/* SVR4_SHARED_LIBS */

#ifdef BKPT_AT_MAIN

  struct minimal_symbol *msymbol;

  msymbol = lookup_minimal_symbol ("main", symfile_objfile);
  if ((msymbol != NULL) && (msymbol -> address != 0))
    {
      breakpoint_addr = msymbol -> address;
    }
  else
    {
      return (0);
    }

  if (target_insert_breakpoint (breakpoint_addr, shadow_contents) != 0)
    {
      return (0);
    }

#else	/* !BKPT_AT_MAIN */

  struct symtab_and_line sal;

  /* Read the debugger interface structure directly. */

  read_memory (debug_base, (char *) &debug_copy, sizeof (debug_copy));

  /* Set breakpoint at the debugger interface stub routine that will
     be called just prior to each mapping change and again after the
     mapping change is complete.  Set up the (nonexistent) handler to
     deal with hitting these breakpoints.  (FIXME). */

  warning ("'%s': line %d: missing SVR4 support code", __FILE__, __LINE__);

#endif	/* BKPT_AT_MAIN */



So at that point (1992), SVR4 support was quite infant, and BKPT_AT_MAIN,
is mutually exclusive with the other method, and looks quite like an
easy fallback used because nothing else better had been written yet.

Over the years, all the macros disappeared, and got converted into
runtime fallbacks, and we ended up with what we have.

> 
> OTOH as I said current GDB will place the breakpoint to _start first and it
> will miss those libraries anyway.  So it is not a regression.


Right.  So you're okay with the patch as is, right?

> Also nowadays some 3rd party runtime probably more adapts to GDB than vice
> verse.


Certainly.

-- 
Pedro Alves

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Jan Kratochvil]

On Fri, 01 Jun 2012 20:19:29 +0200, Pedro Alves wrote:
> Right.  So you're okay with the patch as is, right?

Yes.


Thanks,
Jan

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Mark Kettenis]

> Date: Fri, 1 Jun 2012 19:45:27 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> 
> Also nowadays some 3rd party runtime probably more adapts to GDB than vice
> verse.

Mwahahaha, take a look at what Android/Bionic did...

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Pedro Alves]

On 06/01/2012 05:21 PM, Pedro Alves wrote:

> 
> 2012-06-01  Joakim Tjernlund  <Joakim.Tjernlund@transmode.se>
> 
> 	* solib-svr4.c (enable_break): Don't fallback to setting the solib
> 	event breakpoint at _start, __start or main if a program
> 	interpreter is not found.


I've applied this now.

-- 
Pedro Alves

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Maciej W. Rozycki]

On Fri, 1 Jun 2012, Pedro Alves wrote:

> >> --- a/gdb/solib-svr4.c
> >> +++ b/gdb/solib-svr4.c
> >> @@ -1707,7 +1707,7 @@ enable_break (struct svr4_info *info, int from_tty)
> >>  	}
> >>      }
> >>
> >> -  if (!current_inferior ()->attach_flag)
> >> +  if (interp_name != NULL && !current_inferior ()->attach_flag)
> >>      {
> >>        for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++)
> >>  	{
> > 
> > It has a regression in the case below.
> > 
> > OTOH one has to strip _start to make it a regression as with _start GDB did not
> > catch startup libraries even before.
> 
> 
> Yeah, that's a really contrived example.  You're relying on stopping at main,
> not when the DSO is really loaded (_dl_debug_state) to set the breakpoint.
> I can see _start not existing, with the entry point named something else,
> but if you strip your static binary to miss _dl_debug_state, you won't get
> main either.  (and then static binaries that dlopen aren't something you'd
> want to do normally.)

 Not really that contrived, glibc itself will dlopen(3) any NSS modules 
required even from static binaries (unless you configure the library in a 
non-standard way, that is yet more horrible a case) and I reckon there are 
real life examples that make use of that feature (and explicit provisions 
in glibc to handle a static and a dynamic copy of libc code to be loaded 
both at once; it matters for things like malloc(3) if nothing else).

 If this scenario cannot be handled as one would expect and in a clean 
way, then perhaps we need to arrange for another shared-library event hook 
in glibc to be exported from static dlopen(3) code (e.g. a special section 
that won't ever be stripped unless tried really, really hard).  Of course 
as soon as one dynamic module has been loaded, then there'll be a copy of 
the dynamic linker most likely pulled in too with its own shared-library 
event hook (I think shared modules that have not been linked against 
libc.so have not been supported beyond libc 5 on glibc systems, i.e. from 
glibc 2.0 on; this may have to be double-checked though).

 Can't speak of other libc implementations.

  Maciej

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Pedro Alves]

On 06/07/2012 12:59 AM, Maciej W. Rozycki wrote:

> On Fri, 1 Jun 2012, Pedro Alves wrote:
> 
>>>> --- a/gdb/solib-svr4.c
>>>> +++ b/gdb/solib-svr4.c
>>>> @@ -1707,7 +1707,7 @@ enable_break (struct svr4_info *info, int from_tty)
>>>>  	}
>>>>      }
>>>>
>>>> -  if (!current_inferior ()->attach_flag)
>>>> +  if (interp_name != NULL && !current_inferior ()->attach_flag)
>>>>      {
>>>>        for (bkpt_namep = bkpt_names; *bkpt_namep != NULL; bkpt_namep++)
>>>>  	{
>>>
>>> It has a regression in the case below.
>>>
>>> OTOH one has to strip _start to make it a regression as with _start GDB did not
>>> catch startup libraries even before.
>>
>>
>> Yeah, that's a really contrived example.  You're relying on stopping at main,
>> not when the DSO is really loaded (_dl_debug_state) to set the breakpoint.
>> I can see _start not existing, with the entry point named something else,
>> but if you strip your static binary to miss _dl_debug_state, you won't get
>> main either.  (and then static binaries that dlopen aren't something you'd
>> want to do normally.)
> 
>  Not really that contrived, glibc itself will dlopen(3) any NSS modules 
> required even from static binaries (unless you configure the library in a 
> non-standard way, that is yet more horrible a case) and I reckon there are 
> real life examples that make use of that feature (and explicit provisions 
> in glibc to handle a static and a dynamic copy of libc code to be loaded 
> both at once; it matters for things like malloc(3) if nothing else).


That's basically the same thing.  With either that, or explicitly linking a
program that calls dlopen with "-static -ldl", you end up with "_dl_debug_state"
built into your binary, so the "_start" or "main" "fallbacks" are
never triggered.  If you strip your binary, GDB won't find "_dl_debug_state",
but then it won't find "_start" nor "main" either!  So it is a contrived
example to strip "_dl_debug_state" and "_start" but not "main", because
that's not something that is natural to do.

>  If this scenario cannot be handled as one would expect and in a clean 
> way, then perhaps we need to arrange for another shared-library event hook 
> in glibc to be exported from static dlopen(3) code (e.g. a special section 
> that won't ever be stripped unless tried really, really hard).


"_dl_debug_state" ends up available on static links too, I don't see what
is there to do.

-- 
Pedro Alves

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Jan Kratochvil]

On Fri, 08 Jun 2012 14:09:48 +0200, Pedro Alves wrote:
> If you strip your binary, GDB won't find "_dl_debug_state",
> but then it won't find "_start" nor "main" either!  So it is a contrived
> example to strip "_dl_debug_state" and "_start" but not "main", because
> that's not something that is natural to do.

strip "_dl_debug_state" was just a simulation of ld.so with
incompatible/unimplemented state point.  Nobody is going to strip just any
specific symbols in real world.

I still do not see why 'main' was not left there as it would not hurt and it
could help.  OTOH some real world case (some incompatible ld.so state point
name + build) should be given first before finding a solution for it.



Regards,
Jan

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Pedro Alves]

On 06/08/2012 01:38 PM, Jan Kratochvil wrote:
> I still do not see why 'main' was not left there as it would not hurt and it
> could help.

The original patch was trivial, and a one liner.  I preferred not requiring
bigger changes and risk needing to require copyright assignment for that patch.
Then, GDB has not been trapping on "main", but on "_start" for static binaries
for a long time, so that even feels like a separate "feature" to me.  I even feel
like we could/should drop the "_start/main" fallback from svr4 handling.  It's
just historic at this point, as far as I could ascertain.  If those are
really needed on some system, then a comment in the code mentioning such system
is warranted.

> OTOH some real world case (some incompatible ld.so state point

> name + build) should be given first before finding a solution for it.


That's my view too.  And if that case would be found, we might find
a better solution instead of trapping _start or main.

-- 
Pedro Alves

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Mark Kettenis]

> Date: Fri, 08 Jun 2012 14:07:14 +0100
> From: Pedro Alves <palves@redhat.com>
> 
> On 06/08/2012 01:38 PM, Jan Kratochvil wrote:
> > I still do not see why 'main' was not left there as it would not hurt and it
> > could help.
> 
> The original patch was trivial, and a one liner.  I preferred not
> requiring bigger changes and risk needing to require copyright
> assignment for that patch.  Then, GDB has not been trapping on
> "main", but on "_start" for static binaries for a long time, so that
> even feels like a separate "feature" to me.

The problem here is that "_start" is by no means a standardized name,
whereas "main" is (although there are some exceptions).

> I even feel like we could/should drop the "_start/main" fallback
> from svr4 handling.  It's just historic at this point, as far as I
> could ascertain.  If those are really needed on some system, then a
> comment in the code mentioning such system is warranted.

Please don't do this.  The fallback is useful when bringing up GDB on
a new platform that decided to use yet another name for the ld.so
state point "function".  Or in other cases where for some reason
placing breakpoints in ld.so doesn't work but putting them in the
executable itself does work.  I've been in that situation at least a
couple of times in the past couple of years.

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Pedro Alves]

On 06/08/2012 02:36 PM, Mark Kettenis wrote:

>> Date: Fri, 08 Jun 2012 14:07:14 +0100
>> From: Pedro Alves <palves@redhat.com>
>>
>> On 06/08/2012 01:38 PM, Jan Kratochvil wrote:
>>> I still do not see why 'main' was not left there as it would not hurt and it
>>> could help.
>>
>> The original patch was trivial, and a one liner.  I preferred not
>> requiring bigger changes and risk needing to require copyright
>> assignment for that patch.  Then, GDB has not been trapping on
>> "main", but on "_start" for static binaries for a long time, so that
>> even feels like a separate "feature" to me.
> 
> The problem here is that "_start" is by no means a standardized name,
> whereas "main" is (although there are some exceptions).


Yes, I've mentioned that myself in this thread.
The solution is then to set the breakpoint at the elf's entry point,
not "_start" literally.

>> I even feel like we could/should drop the "_start/main" fallback
>> from svr4 handling.  It's just historic at this point, as far as I
>> could ascertain.  If those are really needed on some system, then a
>> comment in the code mentioning such system is warranted.
> 
> Please don't do this.  The fallback is useful when bringing up GDB on
> a new platform that decided to use yet another name for the ld.so
> state point "function".  


Oh come on, for bring up, just hack GDB and add "main" or whatever
until you fix things properly.  ;-)

> Or in other cases where for some reason

> placing breakpoints in ld.so doesn't work but putting them in the
> executable itself does work.  I've been in that situation at least a
> couple of times in the past couple of years.


Okay, that'd be for dynamically linked executables.
I'd buy this, but I'd love to hear more about it.  The current fallback
still leaves dlopen out in this case.

-- 
Pedro Alves

Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot

[Maciej W. Rozycki]

On Fri, 8 Jun 2012, Pedro Alves wrote:

> [...] So it is a contrived
> example to strip "_dl_debug_state" and "_start" but not "main", because
> that's not something that is natural to do.

 Indeed, I missed that you referred to that peculiarity rather than 
dlopening from a static binary in general.

> "_dl_debug_state" ends up available on static links too, I don't see what
> is there to do.

 It can be stripped from a static binary, while it always stays as a 
dynamic symbol in ld.so, even if you strip the dynamic linker.  However in 
practice that probably does not matter indeed.

  Maciej