[uClibc]ARM/Linux OSABI problems in gdb
Daniel Jacobowitz
drow at mvista.com
Thu Aug 15 14:36:25 UTC 2002
On Thu, Aug 15, 2002 at 08:00:24AM -0600, Erik Andersen wrote:
> On Wed Aug 14, 2002 at 05:14:10PM +0200, Simon Posnjak wrote:
> > > ... wait! I know what's wrong. Does uClibc provide a .note.ABI-tag
> > > section, like glibc does? If not, that needs to be corrected, or GDB
> > > needs to find some other way to recognize uClibc binaries.
> >
> > I'm using a 2.4.18 kernel, cross-compiler 2.95.3 and uClibc 0.9.14.
> > Please cc Daniel the answer, becouse he isn't on this list (he's one of
> > the gdb heckers)
>
> Hi Daniel, how's life treating you? No, uClibc does not
Pretty good :)
> currently provide a ".note.ABI-tag" section. Looking at glibc I
> can that glibc-2.2.5/csu/abi-note.S is adding such a thing. Can
> you explain the mechanism by which gdb makes use of this thing?
> Do I need a uClibc specific ABI tag, or shall I just use the
> uClibc "2,0,0" one?
Well, uClibc uses the same binary ABI as glibc on all Linux platforms,
I assume? Calling convention, etc? So I believe there's no need to
use a different tag than glibc uses. The code recognizing this is:
name_length = bfd_h_get_32 (abfd, note);
data_length = bfd_h_get_32 (abfd, note + 4);
note_type = bfd_h_get_32 (abfd, note + 8);
if (name_length == 4 && data_length == 16 && note_type == NT_GNU_ABI_TAG
&& strcmp (note + 12, "GNU") == 0)
{
int os_number = bfd_h_get_32 (abfd, note + 16);
switch (os_number)
{
case GNU_ABI_TAG_LINUX:
*os_ident_ptr = GDB_OSABI_LINUX;
break;
> Does this only occur when using gdbserver? I've certainly done a
> lot of debugging with gdb on uClibc linked binaries and in
> general things work great. The only wierdness I've seen is that
No, it happens under CVS gdb or gdbserver. The feature is pretty new.
> debugging threads under uClibc doesn't work properly (gives me
> realtime signal 'SIG32'). So while we are on the subject of C
> lib/gdb interaction... Looks like I need to do something with a
> magic .note section. And I'm guessing I probably need to do
> something special for pthreads.
Yeah. For pthreads you need some amount of debugging support in the
library; in glibc it is in "linuxthreads_db". GDB will dlopen
libthread_db.so.1 (or gdbserver will link to it) and use that to get
information about threads. Let me know if you need some pointers for
that.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
More information about the uClibc
mailing list