Hi Carmelo, Filippo, On Tue, May 10, 2011 at 12:08 PM, Carmelo AMOROSO <[email protected]>wrote:
> On 5/3/2011 8:50 AM, Thomas De Schampheleire wrote:
> > Hi Carmelo,
> >
> >>
> >>> Unfortunately, backtrace_symbols() is not yet ok. According to the
> >>> expected output of the example I took from [1], static functions
> >>> simply have no symbolic resolution in the glibc version; only a
> >>> pointer is shown.
> >>>
> >>> However, with the current uClibc / libgcc implementation, a symbolic
> >>> name *is* shown for static functions, but it is wrong. Referring to
> >>> the example code, the entry referring to myfunc2 is printed as
> >>> 'myfunc'. If you change the code and make myfunc static and myfunc2
> >>> global, then all entries referring to myfunc are printed as 'myfunc2'.
> >>> This is problematic in my opinion.
> >>>
> >>> I haven't looked into detail into backtrace_symbols yet. I also don't
> >>> know whether the error is in libgcc or libubacktrace. Any thoughts are
> >>> appreciated.
> >>>
> >>
> >> I'll give a look asap.
> >
> > According to the man page of dladdr, which is used to obtain the symbol
> names,
> >
> > "The function dladdr() takes a function pointer and tries to resolve
> > name and file where it is located. Information is stored in the
> > Dl_info structure:
> >
> > typedef struct {
> > const char *dli_fname;/* Filename of defining object */
> > void *dli_fbase; /* Load address of that object */
> > const char *dli_sname;/* Name of nearest lower symbol */
> > void *dli_saddr; /* Exact value of nearest symbol */
> > } Dl_info;
> >
> > dladdr() returns 0 on error, and non-zero on success. "
> >
> > I think the 'nearest symbol' is biting us. The dladdr function doesn't
> > know about static functions, and hence the provided name is incorrect.
> > If there is a way to obtain the size of the returned symbol in some
> > way, then we would be able to determine whether the name is valid (by
> > comparing the offset). If it isn't, we just return an empty name.
> > Alternatively, if there would be another method that does know about
> > static functions, then that would help as well.
> >
> >>
> >> Really many thanks for your feedback and testing.
> >
> > You're very welcome. Thanks to you for taking this up. A backtrace
> > functionality is really something useful!
> >
> > Best regards,
> > Thomas
> >
>
> Hi Thomas,
> I've pushed a fix in dladdr by Filippo, that fixed the issue at least on
> SH (and I guess other platform).
> Looking at glibc, it seems that it could need some arch specific bits
> for powerpc, but instead of trusting glibc, I'd ask you to test on real hw.
>
The fix in dladdr by Filippo only changes one of two very similar instances
of that line. A bit lower, outside the __LDSO_GNU_HASH_SUPPORT__ block, is
an identical line. I had to apply the same fix there as well, before it
worked for me. I'm not sure whether this is due to architectural differences
or rather configuration differences.
I attach the patch to this mail for your convenience, but note that this is
not against the uclibc master but against 0.9.31.
Thanks Filippo for fixing this!
Best regards,
Thomas
uClibc-0.9.31-backtrace-03.patch
Description: Binary data
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
