Solved..
So, it appears elf_machine_relative() was never implemented for MIPS.
Thats why the debug strings _dl_reltypes_tab are not fixed up.
Well this is a real bug, but only if you turn on LD_DEBUG.
I have a patch that I will post.
The segfault problem I am seeing, the first time a
The debug segfault occurs when the reloc flag is set.
Looks like the _dl_reltypes_tab symbol is not fixed up correctly in ldso.
I don't really understand this.
gdb shows _dl_reltypes_tab as 0x9af0, which happens to be the offset in
the file.
But I couldn't find the symbol with objdump.
How do
So, it appears elf_machine_relative() was never implemented for MIPS.
Thats why the debug strings _dl_reltypes_tab are not fixed up.
Is anyone else trying to use uClibc with MIPS ?
Colin..
Colin Whittaker wrote:
The debug segfault occurs when the reloc flag is set.
Looks like the
I turned on SUPPORT_LD_DEBUG=y
Now with LD_DEBUG=all, it segfaults everytime.
Without the LD_DEBUG=all, it runs without segfault, except the very
first time...
At least I have consistent behavior now.
Here is the output of
# LD_DEBUG=all scp
_dl_get_ready_to_run:587:
I am seeing what Nigel saw in the thread of the same name.
I am running on mips.
Basically after the ldso loads everything it goes and tries to run the
init function with DL_CALL_FUNC_AT_ADDR().
First time it runs __GI___uClibc_init which is in libc.so.0
Second time it points to something
On Fri, Mar 28, 2008 at 5:42 PM, Nigel Kukard [EMAIL PROTECTED] wrote:
Yo,
Can't see anything, I think you should add printouts in __uClibc_init()
to see if you get there, use the write() sys call as I don't think you
can use any of the libc print functions.
Non PIE rpm
On Sat, 2008-03-29 at 16:25 +0100, Denys Vlasenko wrote:
On Saturday 29 March 2008 07:22, Nigel Kukard wrote:
Stupid busybox, it didn't export the env variable I'm rebuilding a
static sh now.
What version of stupid busybox is that, which shell (ash I think?),
and what
On Fri, 2008-03-28 at 19:17 +0100, Carmelo Amoroso wrote:
Bernhard Fischer wrote:
On Fri, Mar 28, 2008 at 04:42:21PM +, Nigel Kukard wrote:
Should I debug this further or just work with the old implementation?
Well, it would be generally nice if the new linuxthreads would work on
On Sun, 2008-03-30 at 12:45 +0200, Joakim Tjernlund wrote:
Well, it would be generally nice if the new linuxthreads would work on
x86 if you find the time, since i don't quite see much progress in the
NPTL camp.
I'm lucky having nptl on my sh4 ;-)
I don't know if there is
Joakim Tjernlund wrote:
On Fri, 2008-03-28 at 19:17 +0100, Carmelo Amoroso wrote:
Bernhard Fischer wrote:
On Fri, Mar 28, 2008 at 04:42:21PM +, Nigel Kukard wrote:
Should I debug this further or just work with the old implementation?
Well, it would be generally nice if the new
On Thu, 2008-03-27 at 22:17 +, Nigel Kukard wrote:
Hi,
This trace looks like it is missing LD_DEBUG=1 rpm or LD_DEBUG=all
rpm,
such a trace can get very big so you need to trim it down before
posting. You also need SUPPORT_LD_DEBUG=y in .config
Stupid busybox,
HI,
Can't see anything, I think you should add printouts in __uClibc_init()
to see if you get there, use the write() sys call as I don't think you
can use any of the libc print functions.
Non PIE rpm works I guess?
Does rpm work in glibc, both PIE and non PIE?
Jocke
_malloc:921:
Yo,
Can't see anything, I think you should add printouts in __uClibc_init()
to see if you get there, use the write() sys call as I don't think you
can use any of the libc print functions.
Non PIE rpm works I guess?
Does rpm work in glibc, both PIE and non PIE?
Jocke
On Fri, Mar 28, 2008 at 04:42:21PM +, Nigel Kukard wrote:
Should I debug this further or just work with the old implementation?
Well, it would be generally nice if the new linuxthreads would work on
x86 if you find the time, since i don't quite see much progress in the
NPTL camp.
Nigel Kukard wrote:
Yo,
Can't see anything, I think you should add printouts in __uClibc_init()
to see if you get there, use the write() sys call as I don't think you
can use any of the libc print functions.
Non PIE rpm works I guess?
Does rpm work in glibc, both PIE and non PIE?
Jocke
Bernhard Fischer wrote:
On Fri, Mar 28, 2008 at 04:42:21PM +, Nigel Kukard wrote:
Should I debug this further or just work with the old implementation?
Well, it would be generally nice if the new linuxthreads would work on
x86 if you find the time, since i don't quite see much progress
I'm dumping loadaddr and func just before that segfault so ignore the
line numbers (i have half a gazillion lines of debugging) the only
thing that changes is the loadaddr, the func value is always the same.
_dl_get_ready_to_run:838: We got here: 838, loadaddr = 0xb7bdc000
On Thu, 2008-03-27 at 14:56 +, Nigel Kukard wrote:
I'm dumping loadaddr and func just before that segfault so ignore the
line numbers (i have half a gazillion lines of debugging) the only
thing that changes is the loadaddr, the func value is always the same.
On Thu, 2008-03-27 at 16:52 +0100, Joakim Tjernlund wrote:
On Thu, 2008-03-27 at 14:56 +, Nigel Kukard wrote:
I'm dumping loadaddr and func just before that segfault so ignore the
line numbers (i have half a gazillion lines of debugging) the only
thing that changes is the
_dl_get_ready_to_run:838: We got here: 838, loadaddr = 0xb7b33000
_dl_get_ready_to_run:839: We got here: 839, func = U��S���
Segmentation fault
Good for now, I rather have the debug built in to ldso than your hack as
I know the ones in ldso.
I can rebuild everything and remove my
hmm, should not func address change when loadaddr change?
Not sure if its a func address or a string, i just outputted %s ;)
It is a address, print tpnt-loadaddr, tpnt-dynamic_info[DT_INIT] and
dl_elf_func.
dl_elf_func should be tpnt-loadaddr + tpnt-dynamic_info[DT_INIT]
hmm, should not func address change when loadaddr change?
Not sure if its a func address or a string, i just outputted %s ;)
Shouldn't you have a pretty good chance of segfaulting just by virtue of
treating a random address as %s?
More than likely, I stopped when I saw the segfault
Hi,
Ok, here is a vanilla uClibc from SVN its x86 architecture.
i386/pentium-mmx .
$ rpm
argc=1 argv=0xbfbe8094 envp=0xbfbe809c
[SNIP]
_dl_malloc:926: mmapping more memory
_dl_get_ready_to_run:748: Beginning relocation fixups
_dl_get_ready_to_run:831: calling INIT:
This trace looks like it is missing LD_DEBUG=1 rpm or LD_DEBUG=all rpm,
such a trace can get very big so you need to trim it down before
posting. You also need SUPPORT_LD_DEBUG=y in .config
Stupid busybox, it didn't export the env variable I'm rebuilding a
static sh now.
-Original Message-
From: Nigel Kukard [mailto:[EMAIL PROTECTED]
Sent: den 27 mars 2008 20:51
To: [EMAIL PROTECTED]
Cc: uclibc
Subject: Re: uclibc segfault in ldso
This trace looks like it is missing LD_DEBUG=1 rpm or LD_DEBUG=all rpm,
such a trace can get very big so you
Hi,
This trace looks like it is missing LD_DEBUG=1 rpm or LD_DEBUG=all rpm,
such a trace can get very big so you need to trim it down before
posting. You also need SUPPORT_LD_DEBUG=y in .config
Stupid busybox, it didn't export the env variable I'm rebuilding a
static sh
Nigel Kukard wrote:
Hi Guys,
I'm trying to trace a segfault in ldso when running a PIE compiled
binary under uclibc.
Hello,
recently there have been some fixes into the ld.so to cope with problems
in PIE applications.
I suggest you to see if latest SVN release works fine for you.
Carmelo Amoroso wrote:
Nigel Kukard wrote:
Hi Guys,
I'm trying to trace a segfault in ldso when running a PIE compiled
binary under uclibc.
Hello,
recently there have been some fixes into the ld.so to cope with
problems in PIE applications.
I suggest you to see if latest SVN release
HI Carmelo,
I'm trying to trace a segfault in ldso when running a PIE compiled
binary under uclibc.
Hello,
recently there have been some fixes into the ld.so to cope with
problems in PIE applications.
I suggest you to see if latest SVN release works fine for you.
Cheers,
29 matches
Mail list logo
