Re: [Gcl-devel] Re: BFD relocations

[Camm Maguire <camm at enhanced dot com>]

Greetings. and thank you again for your reply!

In brief, I can relocate, but I get SIGILL on apparently correctly
relocated code when trying to execute.

I would be very appreciative if you might save me the pain of
searching through the kernel sources and brief me on what raises
SIGILL on ppc.  I'm already aware of divide by zero, and of course an
unknown opcode, but neither seems to be the case here.  Alignment?

Detail:

gcl builds fine on ppc with bfd relocations, including gcl-tk.  When
building maxima-5.6 with it, which involves loading several object
files, I've gotten SIGILL in the following two places when executing
code from kclmac.o:

objdump -d kclmac.o |head -40l

kclmac.o:     file format elf32-powerpc

Disassembly of section .text:

00000000 <init_kclmac>:
->   0:	94 21 ff f0 	stwu	r1,-16(r1)
   4:	7c 08 02 a6 	mflr	r0
   8:	90 01 00 14 	stw	r0,20(r1)
   c:	3c 60 00 00 	lis	r3,0
  10:	38 63 00 00 	addi	r3,r3,0
  14:	4c c6 31 82 	crclr	4*cr1+eq
  18:	48 00 00 01 	bl	18 <init_kclmac+0x18>
  1c:	80 01 00 14 	lwz	r0,20(r1)
->  20:	7c 08 03 a6 	mtlr	r0
  24:	38 21 00 10 	addi	r1,r1,16
  28:	4e 80 00 20 	blr

0000002c <L1>:
  2c:	94 21 ff e0 	stwu	r1,-32(r1)
  30:	7c 08 02 a6 	mflr	r0

r0 contains:

r0             0x1003a5a8	268674472


Here's the gdb output:

(gdb) file /home/camm/gcl/unixport/saved_gcl
file /home/camm/gcl/unixport/saved_gcl
Reading symbols from /home/camm/gcl/unixport/saved_gcl...done.
(gdb) hello
r /home/camm/gcl/unixport < foo
r /home/camm/gcl/unixport < foo
Starting program: /home/camm/gcl/unixport/saved_gcl /home/camm/gcl/unixport < foo
GCL (GNU Common Lisp)  Version(2.5.0) Mon Jun  3 23:37:07 EDT 2002
Licensed under GNU Library General Public License
Contains Enhancements by W. Schelter
Loading init.lsp
Finished loading init.lsp

>
Loading sysdef.lisp
Loading make.lisp
Finished loading make.lisp
Loading maxima-package.lisp
Finished loading maxima-package.lisp
Finished loading sysdef.lisp
T

>
Loading /home/camm/gcl/lsp/sys-proclaim.lisp
Finished loading /home/camm/gcl/lsp/sys-proclaim.lisp
T

>
Loading sys-proclaim.lisp
Finished loading sys-proclaim.lisp
T

>
NIL

>
NIL

>
NIL

>
Program received signal SIGILL, Illegal instruction.
0x1082f020 in ?? ()
(gdb) hello
hello
p/x *((char *)0x1082f020-20)@40
p/x *((char *)0x1082f020-20)@40
$1 = {0x3c, 0x60, 0x10, 0x83, 0x38, 0x63, 0x0, 0x0, 0x4c, 0xc6, 0x31, 0x82, 
  0x4b, 0x80, 0xb6, 0x69, 0x80, 0x1, 0x0, 0x14, 0x7c, 0x8, 0x3, 0xa6, 0x38, 
  0x21, 0x0, 0x10, 0x4e, 0x80, 0x0, 0x20, 0x94, 0x21, 0xff, 0xe0, 0x7c, 0x8, 
  0x2, 0xa6}
(gdb) i reg r0
i reg r0
r0             0x1003a5a8	268674472


Any help most appreciated!

Take care,



Daniel Jacobowitz <drow@mvista.com> writes:

> On Mon, Jun 03, 2002 at 06:08:03PM -0400, Camm Maguire wrote:
> > Greetings, and thanks for your reply!
> > 
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > 
> > > On Sun, Jun 02, 2002 at 11:42:37PM -0400, Camm Maguire wrote:
> > > > Greetings!  I saw your post about bfd_get_relocated_section_contents
> > > > usage in gdb, and was pleasantly surprised that you had found the same
> > > > approach I've been trying to implement over the past few days in gcl
> > > > for loading, relocating, and executing objects at runtime in Lisp.  
> > > > 
> > > > Problem is, it only seems to work in x86 :-(, at least as far as I can
> > > > tell.  Kind of defeats the purpose of using bfd for portability :-).
> > > > I've gone through the mips case in detail, and one cannot even call
> > > > this routine unless one sets the relocateable argument to true, as it
> > > > will result in trying to call _bfd_get_gp_value with a null
> > > > argument.  Likewise on ppc, the relocation apparently succeeds, but
> > > > the source is not correctly relocated. I've noticed that ld doesn't
> > > > seem to actually use this routine, but rather uses a variety of
> > > > backend specific routines ...._relocate_section.  Arguments to this no
> > > > longer seem canonical, alas.
> > > > 
> > > > Just wanted to tap your experience.  Have you tested your gdb patch on
> > > > other archs?  Any work beside x86?  Is there another path through the
> > > > bfd labyrinth that would simply allow one to load a correctly relocated
> > > > section at an arbitrary address, after defining the symbols of course?
> > > 
> > > I used it on PPC, which is where it was originally targetted.  Worked
> > > fine.  I'm going to clean up parts of the GDB support for that and move
> > 
> > Wonderful!  Did you execute the relocated code in your test?
> 
> No.  It was only for resolving symbols in debug information.
> 
> > > them into BFD this week if I can find a cleaner way.  If you search the
> > > gdb-patches archive for (I believe) April, you can find the way I
> > > invoke this.
> > 
> > OK, I found the mail in April.  This is the most current, right?
> 
> Yep.
> 
> > > As for the GP bits, MIPS may need an additional hack.  BFD is not layed
> > 
> > But doesn't ppc, alpha,others? use a gp register too?
> 
> Not PowerPC; Alpha does, and PPC64 I think.
> 
> > I also did as you did:
> > 
> > s->output_section=s;
> > s->vma=my_target_memory_address
> > 
> > Need I actually create an output_section, or should this suffice?
> 
> Should suffice for simple relocation, yes.
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah