gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Re: BFD relocations


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: BFD relocations
Date: 04 Jun 2002 17:33:57 -0400

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 <address@hidden> writes:

> On Mon, Jun 03, 2002 at 06:08:03PM -0400, Camm Maguire wrote:
> > Greetings, and thanks for your reply!
> > 
> > Daniel Jacobowitz <address@hidden> 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
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

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



reply via email to

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