bug-dejagnu
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-dejagnu] Re: wrapper functions that ``call themselves'' break mn103


From: Andrew Cagney
Subject: [Bug-dejagnu] Re: wrapper functions that ``call themselves'' break mn10300 -mrelax
Date: Thu, 07 Aug 2003 22:04:58 -0400
User-agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223

On Jul 29, 2003, Andrew Cagney <address@hidden> wrote:


Alex, just an aside.  The mn10300 should no longer use those wrapper
functions.


This is exactly what the patch I posted fixes :-)  Does this mean it's
approved for the GDB tree?

Ah, doh!  Yes, I assume it's gone into dejagnu.

Andrew

--- Begin Message --- Subject: wrapper functions that ``call themselves'' break mn10300 -mrelax Date: 29 Jul 2003 03:10:35 -0300 User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
I couldn't figure out what exactly broke the long-standing fact that
dejagnu/testglue.c, used in mn10300-sim and several other dejagnu
baseboards, contains wrapper functions that call the original
unwrapped names, e.g., __wrap_abort() calls __real_abort() and then
abort().  Also, __wrap_main() calls __real_main() and then exit() (as
opposed to either __wrap_exit() or __real_exit()).

This causes a very serious problem to the mn10300 linker, when doing
linker relaxations.

The problem is that say __wrap_exit is added to the symbol table of
the testglue.o abfd twice: once when the symbol is first defined, and
once when elf_merge_symbol() calls bfd_wrapped_link_hash_lookup() for
the undefined symbol entry corresponding to abort() or exit() is
encountered, that is mapped to the same hash.

This causes a problem when mn10300 attempts to do adjust the symbol
values within their sections, after removing some bytes from before
them, near the end of mn10300_elf_relax_delete_bytes().

I've been trying to find a clean and efficient way to get
elf_merge_symbols() to skip such duplicate definitions, but I couldn't
think of any.  I'm not even sure it would be correct to arrange for
elf_merge_symbols() to remove duplicate entries from the symhashes
array of a bfd.  Even if it is, there's no efficient way to remove
duplicates, other than creating a per-bfd hash table.  Does anyone
have any clever ideas?

As for dejagnu, I managed to work around the problem by replacing
explicit references to exit() and abort() with references to
ORIG_EXIT() and ORIG_ABORT(), but I'm not sure this would be
appropriate either.  Another work around, that fixed the problem in
this particular platform, was to tell dejagnu that the mn10300 sim
does actually return the exit status from the programs, which I found
to be true but not reflected in the mn10300-sim.exp baseboard file.
Here's the patch for the file.  Ok for the GDB tree?

Index: dejagnu/ChangeLog
from  Alexandre Oliva  <address@hidden>

        * baseboards/mn10300-sim.exp: We don't need_status_wrapper.

Index: dejagnu/baseboards/mn10300-sim.exp
===================================================================
RCS file: /cvs/uberbaum/dejagnu/baseboards/mn10300-sim.exp,v
retrieving revision 1.2
diff -u -p -r1.2 mn10300-sim.exp
--- dejagnu/baseboards/mn10300-sim.exp 21 Apr 2002 08:46:47 -0000 1.2
+++ dejagnu/baseboards/mn10300-sim.exp 29 Jul 2003 06:09:59 -0000
@@ -26,8 +26,8 @@ set_board_info ldflags  "[libgloss_link_
 # Simulator linker script.
 set_board_info ldscript "-Tsim.ld"
 
-# The simulator doesn't return exit statuses and we need to indicate this.
-set_board_info needs_status_wrapper  1
+# The simulator does return exit statuses.
+#set_board_info needs_status_wrapper  1
 
 # We can't pass args to the simulator or get exit status back from the
 # simulator, nor does the simulator support real signals.
-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 address@hidden, gcc.gnu.org}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist                Professional serial bug killer

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]