This is just a curiosity question and could be a bit of topic.
Why is it that most libraries (like glibc) prefix all their
functions with __. Even the ones that will eventually be exported.
I've come up with two possible reasons:
1) avoid global namespace polution. This can also be avoided
by gro
It used to be that if you attach gdb before there are any threads,
you had to do some diddling after the threads got created to make
it notice them. e.g. "info thr" after you've hit return, to make
sure gdb knows about all the threads and so sets their exception ports.
__
Oh, I lie. It used to be that way, but now the exec server is involved so
it should be stopping the first thread before it starts. You'll have to
figure out what's going on there. But the method I described should let
you debug it regardless of exec server cooperation.
___
On Sat, Jun 16, 2001 at 07:41:32PM -0400, Roland McGrath wrote:
> It's not your breakpoint, it's the starting trap. You can't use "run" to
> debug initialization, because the initial SIGTRAP is sent after libc is
> initialized. You need to attach to the task before it starts running.
Ok, I us
It's not your breakpoint, it's the starting trap. You can't use "run" to
debug initialization, because the initial SIGTRAP is sent after libc is
initialized. You need to attach to the task before it starts running.
Use shd to run it:
bash# /bin/shd
# pause
# ld.so /bin/rpctrace
Pausing (child
On Sat, Jun 16, 2001 at 06:59:39PM -0400, Roland McGrath wrote:
>
> Well, I think that is because you are getting an error in the very first
> place that one can happen. _dl_map_object prints when it's about to load
> an object--unless it's the main program being loaded or a _dl_open call.
> I'm
On Sat, Jun 16, 2001 at 06:54:39PM -0500, Neal H Walfield wrote:
> You want:
>
> LD_DEBUG=foo LD_LIBRARY_PATH=/new-glibc:/lib /new-glibc/ld-2.2.3.so /bin/rpctrace
>-^
Doesn't make a difference.
Marcus
___
Bug
> Hi,
>
> I tried
>
> LD_DEBUG=foo LD_LIBRARY_PATH=/new-glibc /new-glibc/ld-2.2.3.so /bin/rpctrace
>
> with foo being one of those which you get when setting foo as "help"
> (like files, libs, statistics etc).
>
> Not a single foo prints anything. I always get:
>
> /bin/rpctrace: error while
> I tried
>
> LD_DEBUG=foo LD_LIBRARY_PATH=/new-glibc /new-glibc/ld-2.2.3.so /bin/rpctrace
>
> with foo being one of those which you get when setting foo as "help"
> (like files, libs, statistics etc).
>
> Not a single foo prints anything. I always get:
>
> /bin/rpctrace: error while loading
Hi,
I tried
LD_DEBUG=foo LD_LIBRARY_PATH=/new-glibc /new-glibc/ld-2.2.3.so /bin/rpctrace
with foo being one of those which you get when setting foo as "help"
(like files, libs, statistics etc).
Not a single foo prints anything. I always get:
/bin/rpctrace: error while loading shared librarie
> As there were a lot of entries, I thought it might be easier if they
> were inline.
If you had made fresh patches yesterday, then it would have.
But your patches were relative to an old repository state.
> Do you want a format like this:
>
> foo/ChangeLog
>
> Changes in foo.
>
> bar/Chang
> > Do you get "Crashing system; essential task exec died"?
>
> I have gotten that. This time, however, I did not get a chance to look
> at the console before init crashed the system.
Perhaps you should hack init to do a device_read from the console
before it reboots, so you can see all the ms
On Sat, Jun 16, 2001 at 04:14:41PM -0400, Roland McGrath wrote:
> I've put those in. In future, please follow the convention of pasting
> ChangeLog entries into your message alone, not as patches. Those patches
> often fail to apply.
As there were a lot of entries, I thought it might be easier
I've put those in. In future, please follow the convention of pasting
ChangeLog entries into your message alone, not as patches. Those patches
often fail to apply.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hu
> Do you get "Crashing system; essential task exec died"?
I have gotten that. This time, however, I did not get a chance to look
at the console before init crashed the system.
> init should only do this when the task dies. Normally gdb should reset the
> exception port and catch exceptions and
> Just out of curiosity, is posix_spawn a standard interface? And
> is it reasonable for programs to expect to have it available
> on a system that say, doesn't use glibc?
It's specified by some newfangled draft standard, as a new POSIX option.
It is not a GNU invention. I don't know of any othe
Do you get "Crashing system; essential task exec died"?
If init is rebooting the system, it should print that first.
init should only do this when the task dies. Normally gdb should reset the
exception port and catch exceptions and show them to you, it should not be
killing the task. Anyway, I
On Sat, Jun 16, 2001 at 12:50:14PM -0500, Neal H Walfield wrote:
> While compiling the C library, I got the following:
>
> make: *** make[1]: *** wait: Computer bought the farmmake:
>../sysdeps/mach/hurd/fork.c:469: __fork: Unexpected error: (ipc/mig)
> server died.
> wait: Com
On Sat, Jun 16, 2001 at 05:53:52AM -0400, Roland McGrath wrote:
> It has been noted that the slowness of fork on the Hurd may be a
> substantial factor in uses like large builds. One way to avoid this
> problem is to avoid fork. In glibc we have providing posix_spawn
> and related functions; mo
While compiling the C library, I got the following:
make: *** make[1]: *** wait: Computer bought the farmmake:
../sysdeps/mach/hurd/fork.c:469: __fork: Unexpected error: (ipc/mig)
server died.
wait: Computer bought the farm.. Stop.
Stop.
make[1]: *** Wa
It has been noted that the slowness of fork on the Hurd may be a
substantial factor in uses like large builds. One way to avoid this
problem is to avoid fork. In glibc we have providing posix_spawn
and related functions; most common cases where a program uses fork and exec
directly can be repla
21 matches
Mail list logo
