C++ and PIC code generation...

[Scott Bambrough <scottb at netwinder dot org>]

Attached is some short sample code that illustrates a problem on ARM Linux when
trying to catch an exception in a shared library.  Consider the following:

struct Foo
{
  struct Exc {};
  void bar();
};

void Foo::bar()
{
  cout << "Throwing" << endl;
  throw Exc();
}

void doit(Foo & arg)
{
  try
  {
    arg.bar();
  }
  catch (Foo::Exc & e)
  {
    cout << "Caught it" << endl;
  }
}

The above code works on x86 if doit() is in a shared library.  On ARM Linux,
doit() aborts if it is in a shared library.  The code aborts calling
__eh_rtime_match.  The problem seems to be the code generated by the compiler
when -fPIC is passed.  On the ARM it generates:

	bl  __eh_rtime_match

AFAIK, it should generate:

	bl  __eh_rtime_match(PLT)

This makes the code work.  I generated an assembler listing, and added the
(PLT)'s by hand to the assembler source and rebuilt the app and libary.  The PIC
code generation on ARM Linux is based on the way the x86 backend does things.

I built this same code on x86 and had a look at the assembler listing.  I was
expecting to see:

	call __eh_rtime_match@plt

I was mildly shocked to see:

	call __eh_rtime_match

I looked at the resulting shared library on x86 using readelf, and
__eh_rtime_match ends up in the PLT.  I'm a little confused about how this is
supposed to work now.  I don't understand how __eh_rtime_match ended up in the
PLT?  Is there something specific with exception handling I am missing?

Scott

Compiler info: 

Reading specs from /usr/lib/gcc-lib/i686-redhat-linux/2.95/specs
gcc version 2.95 19990728 (release)

Reading specs from /usr/lib/gcc-lib/armv4l-unknown-linux-gnu/2.95.2/specs
gcc version 2.95.2 20000516 (release) [Rebel.com]   

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org

armexcept.tar.gz