> Where can I find more info about all of this anyway?
You'll have to be a little more specific. You can start with the ELF spec
to understand what relocs and dynamic relocs are all about.
> Not much of what you have written in this thread makes much sense to me
> since I have only a very va
I reproduced what you saw. The bogus resolution of the _exit refs is an ld
bug. However, we should probably work around it by arranging that _exit be
given a PLT slot. That is necessary for correctness if _exit can ever be
called from ld.so after startup. It probably shouldn't ever be, but the
Poke, would be nice to have this solved by chirstmas. :-) And since I
have no idea what I'm looking at or doing your help is invaluable.
Cheers, and happy hacking!
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hur
> Nor am I exactly sure about how you would like the output from
> this. Anyway, I did a `objdump -rd' on all the noted files, and
> then greped it for _exit.
That doesn't tell you anything useful about the symbols. Use
--syms.
Heres the output of objdump --syms on (I think) all
> Okie, I'm not exactly sure what files go into ld.so.1, but I'm
> assuming that rtld-*.os and dl-*.os.
You'll have to watch the make output and see the commands that make it.
> Nor am I exactly sure about how you would like the output from this.
> Anyway, I did a `objdump -rd' on all the noted f
[sorry for messing up the threading, but I had some smallish problems
with my mail...]
> objdump -rd ld.so.1:
>
> 1560 :
[...]
> 29c3:e8 fc ff ff ff call 29c4
[...]
> objdump -rd rtld.os:
>
> 0570 :
> [...snip...]
>
> objdump -rd ld.so.1:
>
> 1560 :
[...]
> 29c3:e8 fc ff ff ff call 29c4
[...]
> objdump -rd rtld.os:
>
> 0570 :
> [...snip...]
> 19d3:e8 fc ff ff ff call 19d4
> 19d4: R_386_PC32_exit
[...]
This indicates a problem
[Sorry for the late reply, busy with school.]
The PC value suggests some botch relocation or something. Compare
the last several instructions in your gdb disassembly there with
what objdump -rd shows you on ld.so, and on the rtld.os file that
went into making it.
Alright, here is s t
The PC value suggests some botch relocation or something. Compare the last
several instructions in your gdb disassembly there with what objdump -rd
shows you on ld.so, and on the rtld.os file that went into making it.
___
Bug-hurd mailing list
[EMAIL P
On Mon, 24 Nov 2003, Alfred M. Szmidt wrote:
> ld.so.1 breaks a bit if you compile it with gcc 3.3.1 on GNU/Hurd,
Please note that if you are using the Debian gcc packages, then it would
be really gcc-3.3 version 3.3.2-3. On Debian, gcc_3.3.1-2 is a
dependency package which does not contain anyth
> ld.so.1 breaks a bit if you compile it with gcc 3.3.1 on
> GNU/Hurd,
Please note that if you are using the Debian gcc packages, then it
would be really gcc-3.3 version 3.3.2-3. On Debian, gcc_3.3.1-2 is
a dependency package which does not contain anything by itself.
I don't use D
11 matches
Mail list logo
