BFD relocations

BFD relocations

[Camm Maguire]

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?

Any help most appreciated!

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

Re: BFD relocations

[Daniel Jacobowitz]

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
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.

As for the GP bits, MIPS may need an additional hack.  BFD is not layed
out to do what we are doing; I had to fake a great number of callbacks.
Be sure to have output sections and output VMAs for every section set.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: BFD relocations

[Camm Maguire]

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?

> 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?

> 
> 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?

> out to do what we are doing; I had to fake a great number of callbacks.

Indeed.  But the callbacks would be needed in any routine of this
nature, I'd think.  You really do want access to individual relocation
errors, and such a routine will loop ever them in processing the
section.   What it seems is unnecessary is the hash table.  Mips
needed it, so I implemented it as you did.  x86 does not care.

> Be sure to have output sections and output VMAs for every section set.
> 

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?

Take care,

> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 

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

Re: BFD relocations

[Daniel Jacobowitz]

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

Re: [Gcl-devel] Re: BFD relocations

[Camm Maguire]

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

Re: [Gcl-devel] Re: BFD relocations

[Geoff Keating]

> From: Camm Maguire <camm@enhanced.com>
> 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?

Possibly a cache-flushing issue?

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: [Gcl-devel] Re: BFD relocations

[Daniel Jacobowitz]

On Tue, Jun 04, 2002 at 05:33:57PM -0400, Camm Maguire wrote:
> 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?

Cache.  Are you explicitly flushing the data and instruction caches
over the entire loaded range?  If not, you absolutely should try that.

> 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

Those two spots are both apparently undistinguished, and 32 bytes
apart.  Coincidence?  I think not.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [Gcl-devel] Re: BFD relocations

[Camm Maguire]

Greetings!

Daniel Jacobowitz <drow@mvista.com> writes:

> On Tue, Jun 04, 2002 at 05:33:57PM -0400, Camm Maguire wrote:
> > 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?
> 
> Cache.  Are you explicitly flushing the data and instruction caches
> over the entire loaded range?  If not, you absolutely should try that.
> 

Thanks for this suggestion!  I'm afraid I'm a neophyte wrt cache
flushing.  Is there a specific assembly instruction I should add, or
do I flush via a read through the .text and .(s)data sections, or a
copy to some distant memory? 

Thanks again!

> > 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
> 
> Those two spots are both apparently undistinguished, and 32 bytes
> apart.  Coincidence?  I think not.
> 
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 

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

Re: [Gcl-devel] Re: BFD relocations

[Daniel Jacobowitz]

On Tue, Jun 04, 2002 at 06:06:18PM -0400, Camm Maguire wrote:
> Greetings!
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > On Tue, Jun 04, 2002 at 05:33:57PM -0400, Camm Maguire wrote:
> > > 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?
> > 
> > Cache.  Are you explicitly flushing the data and instruction caches
> > over the entire loaded range?  If not, you absolutely should try that.
> > 
> 
> Thanks for this suggestion!  I'm afraid I'm a neophyte wrt cache
> flushing.  Is there a specific assembly instruction I should add, or
> do I flush via a read through the .text and .(s)data sections, or a
> copy to some distant memory? 

You need to do a dcbst (and an icbi for safety) on every cache line. 
That's every 32 bytes on a mainstream PPC processor (16 on the 8xx's
and 64 on the POWER4s).  Like:
  asm ("dcbst 0,%0\n\tsync\n\ticbi 0,%0\n\tsync\n\tisync"
	: : "r" (ptr) : "memory");
That's more paranoid than you need to be, I think, but should work.

> 
> Thanks again!
> 
> > > 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
> > 
> > Those two spots are both apparently undistinguished, and 32 bytes
> > apart.  Coincidence?  I think not.
> > 
> > 
> > -- 
> > Daniel Jacobowitz                           Carnegie Mellon University
> > MontaVista Software                         Debian GNU/Linux Developer
> > 
> > 
> 
> -- 
> Camm Maguire			     			camm@enhanced.com
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [Gcl-devel] Re: BFD relocations

[Camm Maguire]

Greetings!  Many thanks again!

This works without problem!  Hooray!

1) Is it possible to know for sure that a smaller range could be
   flushed safely?
2) Any other machines supported by binutils which require similar
   flushing?  Assembly instructions?
3) Separately, do you know what the alignment requirements are for
   sparc32 user code on a sparc64 system?  I'm getting a SIGBUS on
   Debian sparc, but the relevant addresses seem to be aligned on 8
   byte boundaries, which I thought should be plenty.

Thanks again!

Daniel Jacobowitz <drow@mvista.com> writes:

> On Tue, Jun 04, 2002 at 06:06:18PM -0400, Camm Maguire wrote:
> > Greetings!
> > 
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > 
> > > On Tue, Jun 04, 2002 at 05:33:57PM -0400, Camm Maguire wrote:
> > > > 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?
> > > 
> > > Cache.  Are you explicitly flushing the data and instruction caches
> > > over the entire loaded range?  If not, you absolutely should try that.
> > > 
> > 
> > Thanks for this suggestion!  I'm afraid I'm a neophyte wrt cache
> > flushing.  Is there a specific assembly instruction I should add, or
> > do I flush via a read through the .text and .(s)data sections, or a
> > copy to some distant memory? 
> 
> You need to do a dcbst (and an icbi for safety) on every cache line. 
> That's every 32 bytes on a mainstream PPC processor (16 on the 8xx's
> and 64 on the POWER4s).  Like:
>   asm ("dcbst 0,%0\n\tsync\n\ticbi 0,%0\n\tsync\n\tisync"
> 	: : "r" (ptr) : "memory");
> That's more paranoid than you need to be, I think, but should work.
> 
> > 
> > Thanks again!
> > 
> > > > 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
> > > 
> > > Those two spots are both apparently undistinguished, and 32 bytes
> > > apart.  Coincidence?  I think not.
> > > 
> > > 
> > > -- 
> > > Daniel Jacobowitz                           Carnegie Mellon University
> > > MontaVista Software                         Debian GNU/Linux Developer
> > > 
> > > 
> > 
> > -- 
> > Camm Maguire			     			camm@enhanced.com
> > ==========================================================================
> > "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> > 
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 

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

Re: [Gcl-devel] Re: BFD relocations

[Daniel Jacobowitz]

On Wed, Jun 05, 2002 at 07:03:51PM -0400, Camm Maguire wrote:
> Greetings!  Many thanks again!
> 
> This works without problem!  Hooray!
> 
> 1) Is it possible to know for sure that a smaller range could be
>    flushed safely?

I believe glibc has an "aux" mechanism to convey this.  I don't know
how it works, though.  Geoff?

> 2) Any other machines supported by binutils which require similar
>    flushing?  Assembly instructions?

Almost every machine has some requirements here; if x86 does not expose
them than that is probably a remnant of its CISC beginnings.  You will
need to look through glibc's loader code, I expect.

> 3) Separately, do you know what the alignment requirements are for
>    sparc32 user code on a sparc64 system?  I'm getting a SIGBUS on
>    Debian sparc, but the relevant addresses seem to be aligned on 8
>    byte boundaries, which I thought should be plenty.

Probably again a cache issue.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [Gcl-devel] Re: BFD relocations

[Camm Maguire]

Thanks as always.  Forgot two more:

Daniel Jacobowitz <drow@mvista.com> writes:

> On Wed, Jun 05, 2002 at 07:03:51PM -0400, Camm Maguire wrote:
> > Greetings!  Many thanks again!
> > 
> > This works without problem!  Hooray!
> > 
> > 1) Is it possible to know for sure that a smaller range could be
> >    flushed safely?
> 
> I believe glibc has an "aux" mechanism to convey this.  I don't know
> how it works, though.  Geoff?
> 
> > 2) Any other machines supported by binutils which require similar
> >    flushing?  Assembly instructions?
> 
> Almost every machine has some requirements here; if x86 does not expose
> them than that is probably a remnant of its CISC beginnings.  You will
> need to look through glibc's loader code, I expect.
> 
> > 3) Separately, do you know what the alignment requirements are for
> >    sparc32 user code on a sparc64 system?  I'm getting a SIGBUS on
> >    Debian sparc, but the relevant addresses seem to be aligned on 8
> >    byte boundaries, which I thought should be plenty.
> 
> Probably again a cache issue.
> 

4) Does cache corruption always result in a signal delivery?  -- My
   guess, no.  If so, is the only other definitive symptom of missing
   cache flushing unexplained memory corruption, (which itself of
   course is not definitive)?

5) On RISC machines, when is cache flushing generally necessary, apart
   from the already identified case of reading in executable code and
   jumping to it from within the program?  Why does the write to
   memory on program load not dirty the cache, and instruct the cpu to
   reread from main memory?   It would seem that any case of passing
   function pointers around might require a cache flush.

Take care,

> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 

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

Re: [Gcl-devel] Re: BFD relocations

[Daniel Jacobowitz]

On Wed, Jun 05, 2002 at 08:21:24PM -0400, Camm Maguire wrote:
> Thanks as always.  Forgot two more:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > On Wed, Jun 05, 2002 at 07:03:51PM -0400, Camm Maguire wrote:
> > > Greetings!  Many thanks again!
> > > 
> > > This works without problem!  Hooray!
> > > 
> > > 1) Is it possible to know for sure that a smaller range could be
> > >    flushed safely?
> > 
> > I believe glibc has an "aux" mechanism to convey this.  I don't know
> > how it works, though.  Geoff?
> > 
> > > 2) Any other machines supported by binutils which require similar
> > >    flushing?  Assembly instructions?
> > 
> > Almost every machine has some requirements here; if x86 does not expose
> > them than that is probably a remnant of its CISC beginnings.  You will
> > need to look through glibc's loader code, I expect.
> > 
> > > 3) Separately, do you know what the alignment requirements are for
> > >    sparc32 user code on a sparc64 system?  I'm getting a SIGBUS on
> > >    Debian sparc, but the relevant addresses seem to be aligned on 8
> > >    byte boundaries, which I thought should be plenty.
> > 
> > Probably again a cache issue.
> > 
> 
> 4) Does cache corruption always result in a signal delivery?  -- My
>    guess, no.  If so, is the only other definitive symptom of missing
>    cache flushing unexplained memory corruption, (which itself of
>    course is not definitive)?

Exactly.  There are no definitive symptoms of missing cache flushes
(although each architecture will tend to have a "usual" behavior).

> 5) On RISC machines, when is cache flushing generally necessary, apart
>    from the already identified case of reading in executable code and
>    jumping to it from within the program?  Why does the write to
>    memory on program load not dirty the cache, and instruct the cpu to
>    reread from main memory?   It would seem that any case of passing
>    function pointers around might require a cache flush.

On many RISC systems, and probably many non-RISC, the data cache is not
synchronized to the instruction cache.  The icache will not fetch
blocks from the data cache, only direct from main memory.  So if it's
in-cache and dirty...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [Gcl-devel] Re: BFD relocations

[Camm Maguire]

Greetings!  I found an earlier cache flushing snippet for another
arch:

#define CLEAR_CACHE do { unsigned long ps = getpagesize(); \
			 char *beg = (char *)((unsigned long )(memory->cfd.cfd_start) & ~(ps-1)); \
			 char *end =  ROUND_UP(memory->cfd.cfd_start + \
				          memory->cfd.cfd_size,ps); \
			   mprotect(beg,end-beg,PROT_READ|PROT_WRITE|PROT_EXEC);} while(0)

Can mprotect be used in this way to portably flush the data cache?

Thanks!

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

Re: [Gcl-devel] Re: BFD relocations

[Daniel Jacobowitz]

On Thu, Jun 06, 2002 at 11:14:43PM -0400, Camm Maguire wrote:
> Greetings!  I found an earlier cache flushing snippet for another
> arch:
> 
> #define CLEAR_CACHE do { unsigned long ps = getpagesize(); \
> 			 char *beg = (char *)((unsigned long )(memory->cfd.cfd_start) & ~(ps-1)); \
> 			 char *end =  ROUND_UP(memory->cfd.cfd_start + \
> 				          memory->cfd.cfd_size,ps); \
> 			   mprotect(beg,end-beg,PROT_READ|PROT_WRITE|PROT_EXEC);} while(0)
> 
> Can mprotect be used in this way to portably flush the data cache?

I don't believe this is portable, but I have no idea.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [Gcl-devel] Re: BFD relocations

[Jason R Thorpe]

On Thu, Jun 06, 2002 at 11:57:33PM -0400, Daniel Jacobowitz wrote:

 > > Can mprotect be used in this way to portably flush the data cache?
 > 
 > I don't believe this is portable, but I have no idea.

I certainly wouldn't bet on it.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: [Gcl-devel] Re: BFD relocations

[Paul Koning]

> Greetings!  I found an earlier cache flushing snippet for another
> arch:
>
> #define CLEAR_CACHE do { unsigned long ps = getpagesize(); \
> 			 char *beg = (char *)((unsigned long )(memory->cfd.cfd_start) & ~(ps-1)); \
> 			 char *end =  ROUND_UP(memory->cfd.cfd_start + \
> 				          memory->cfd.cfd_size,ps); \
> 			   mprotect(beg,end-beg,PROT_READ|PROT_WRITE|PROT_EXEC);} while(0)
> 
> Can mprotect be used in this way to portably flush the data cache?

I very much doubt it.  I don't see any real connection between page
protection and the cache.  Some OS might decide that changing
protection is a reason to flush the cache; another might not.  For
some CPU targets this may be necessary or useful, for others it may be
entirely superfluous.

	 paul

Re: [Gcl-devel] Re: BFD relocations

[Camm Maguire]

Greetings!  Thank you all once again.  To finalize this issue for gcl,
could you perhaps guide me as to the following:

1) Is there a central place where I can find the analogous
   data-cache-flushing assembly instructions for the Debian supported
   architectures?  Barring that, decentralized places?

2) The existing gcl code (on x86 for example), loads .text and .data
   sections, and allocates space for .bss but of course doesn't load.
   I've tried not allocating space for .bss on x86, as the section
   flags seem to indicate, and all still works fine.  Is this
   portable?  My eventual intention is to allocate space only if one
   of SEC_ALLOC and SEC_LOAD are set.

3) I don't understand stripping of binaries very well, but I was
   wondering if after relocation I could reclaim some of the space of
   the object by discarding symbol information as when stripping an
   executable.  Does this shrink .text and .data section space, or
   does this just refer to the .strtab etc. sections?

Thanks again! 

Paul Koning <pkoning@equallogic.com> writes:

> > Greetings!  I found an earlier cache flushing snippet for another
> > arch:
> >
> > #define CLEAR_CACHE do { unsigned long ps = getpagesize(); \
> > 			 char *beg = (char *)((unsigned long )(memory->cfd.cfd_start) & ~(ps-1)); \
> > 			 char *end =  ROUND_UP(memory->cfd.cfd_start + \
> > 				          memory->cfd.cfd_size,ps); \
> > 			   mprotect(beg,end-beg,PROT_READ|PROT_WRITE|PROT_EXEC);} while(0)
> > 
> > Can mprotect be used in this way to portably flush the data cache?
> 
> I very much doubt it.  I don't see any real connection between page
> protection and the cache.  Some OS might decide that changing
> protection is a reason to flush the cache; another might not.  For
> some CPU targets this may be necessary or useful, for others it may be
> entirely superfluous.
> 
> 	 paul
> 
> 
> 
> 

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

Re: [Gcl-devel] Re: BFD relocations

[Daniel Jacobowitz]

On Mon, Jun 10, 2002 at 06:35:02PM -0400, Camm Maguire wrote:
> Greetings!  Thank you all once again.  To finalize this issue for gcl,
> could you perhaps guide me as to the following:
> 
> 1) Is there a central place where I can find the analogous
>    data-cache-flushing assembly instructions for the Debian supported
>    architectures?  Barring that, decentralized places?

Glibc.  Under sysdeps/<arch>/.  Good luck.

> 2) The existing gcl code (on x86 for example), loads .text and .data
>    sections, and allocates space for .bss but of course doesn't load.
>    I've tried not allocating space for .bss on x86, as the section
>    flags seem to indicate, and all still works fine.  Is this
>    portable?  My eventual intention is to allocate space only if one
>    of SEC_ALLOC and SEC_LOAD are set.

Huh?  BSS should be marked SEC_ALLOC.

> 3) I don't understand stripping of binaries very well, but I was
>    wondering if after relocation I could reclaim some of the space of
>    the object by discarding symbol information as when stripping an
>    executable.  Does this shrink .text and .data section space, or
>    does this just refer to the .strtab etc. sections?

No loaded segment would change size, in general.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Flushing the d-cache (was Re: BFD relocations)

[Camm Maguire]

Greetings!

Daniel Jacobowitz <drow@mvista.com> writes:

> On Mon, Jun 10, 2002 at 06:35:02PM -0400, Camm Maguire wrote:
> > Greetings!  Thank you all once again.  To finalize this issue for gcl,
> > could you perhaps guide me as to the following:
> > 
> > 1) Is there a central place where I can find the analogous
> >    data-cache-flushing assembly instructions for the Debian supported
> >    architectures?  Barring that, decentralized places?
> 
> Glibc.  Under sysdeps/<arch>/.  Good luck.
> 

OK, here are two proposals -- comments from the experts most welcome!
These are basically working, but not completely yet, still get some
SIGILL's.

arm:

#define CLEAR_CACHE do {\
  void *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; \
  for (;v<ve;v+=16)   {   \
       register unsigned long _beg __asm ("a1") = (unsigned long)(v);	\
       register unsigned long _end __asm ("a2") = (unsigned long)(v+16);\
       register unsigned long _flg __asm ("a3") = 0;			\
       __asm __volatile ("swi 0x9f0002		@ sys_cacheflush"	\
		    : /* no outputs */					\
		    : /* no inputs */					\
		    : "a1");						\
       }\
} while (0)


m68k:
#include <asm/cachectl.h>
#define CLEAR_CACHE do {\
	void *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; \
	for (;v<ve;v+=16)   \
		sys_cacheflush(v,FLUSH_SCOPE_LINE,FLUSH_CACHE_DATA,16);\
	} while(0)


> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 

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

Re: Flushing the d-cache (was Re: BFD relocations)

[Philip Blundell]

On Fri, 2002-06-14 at 16:51, Camm Maguire wrote:
> #define CLEAR_CACHE do {\
>   void *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; \
>   for (;v<ve;v+=16)   {   \
>        register unsigned long _beg __asm ("a1") = (unsigned long)(v);	\
>        register unsigned long _end __asm ("a2") = (unsigned long)(v+16);\
>        register unsigned long _flg __asm ("a3") = 0;			\
>        __asm __volatile ("swi 0x9f0002		@ sys_cacheflush"	\
> 		    : /* no outputs */					\
> 		    : /* no inputs */					\
> 		    : "a1");						\
>        }\

You don't need the loop.  The arm sys_cacheflush can be given arbitrary
regions, it works the cache line size out for itself.

p.

Re: [Gcl-devel] Re: Flushing the d-cache (was Re: BFD relocations)

[Camm Maguire]

Greetings, and thanks for your reply!

With or without the loop, I'm able to build gcl/maxima on arm, and run
most of the 'make test' in the maxima package without failure.  Up
until this point:  is this still not a data cache flushing issue?
SIGILL received, and the assembly and registers look fine in gdb.  As
background, gcl is loading compiled objects at a certain place in
memory, relocating the symbols, (supposedly) flushing the data cache,
and then executing the object.  

I still see this behavior even if all attempts to flush the data cache
are removed.  Makes me think that the swi instruction is no working.
Are there alignment requirements on the arguments?  Why aren't
a1,a2,a3 shown in the assembly?  I've included the CLEAR_CACHE code
and its assembly below as well.

Any pointers/ideas most appreciated!  Arm maxima is very close!


=============================================================================

(Many correct results)
....

..Which was correct
/* ********************** Problem 24. *************** */ 
%Input is
	 1/2	    1/2	 1/2    - p T
SPECINT(T    %J (2 A    T   ) %E     , T)
	       1


The result is
	  - A/p
SQRT(A) %E
---------------
       2
      p

..Which was correct
/* ********************** Problem 25. *************** */ 
%Input is
	 3/2		   - p T
SPECINT(T    %M	     (T) %E     , T)
	       1/2, 1


The result is
       1	        1
6 (--------- + --------------------)
	 1	    1	      1	  2
   1 - -----   (p + -) (1 - -----)
	   1	    2	        1
       p + -		    p + -
	   2		        2
------------------------------------
		   1 4
	      (p + -)
		   2

..Which was correct
/* ********************** Problem 26. *************** */ 
%Input is
(ASSUME(p > A), TRUE)


The result is
TRUE

..Which was correct
/* ********************** Problem 27. *************** */ 
%Input is
	  A T  2      1/2    - p T
SPECINT(%E    T  ERF(T	 ) %E	  , T)


The result is
	   1		        1			   3
15 (--------------- - ---------------------- + -------------------------)
	   1			 1	 3/2	        2    1	     5/2
    SQRT(----- + 1)   (p - A) (----- + 1)      4 (p - A)  (----- + 1)
	 p - A		       p - A			   p - A
-------------------------------------------------------------------------
				       7/2
			      4 (p - A)

..Which was correct
Congratulations: No differences!
No Errors Found

Program received signal SIGILL, Illegal instruction.
0x00036ee0 in number_to_double (x=0xb7212c) at number.c:239
239			return(number_to_double(x->rat.rat_num) /
(gdb) hello
hello
hello
hello
hello
disassemble
disassemble
Dump of assembler code for function number_to_double:
0x36e58 <number_to_double>:	mov	r12, sp
0x36e5c <number_to_double+4>:	stmdb	sp!, {r4, r11, r12, lr, pc}
0x36e60 <number_to_double+8>:	sfm	f4, 1, [sp, -#12]!
0x36e64 <number_to_double+12>:	sub	r11, r12, #4	; 0x4
0x36e68 <number_to_double+16>:	sub	sp, sp, #4	; 0x4
0x36e6c <number_to_double+20>:	str	r0, [r11, -#32]
0x36e70 <number_to_double+24>:	ldr	r3, [r11, -#32]
0x36e74 <number_to_double+28>:	ldrb	r3, [r3]
0x36e78 <number_to_double+32>:	sub	r3, r3, #1	; 0x1
0x36e7c <number_to_double+36>:	cmp	r3, #4	; 0x4
0x36e80 <number_to_double+40>:	ldrls	pc, [pc, r3, lsl #2]
0x36e84 <number_to_double+44>:	b	0x36f0c <number_to_double+180>
0x36e88 <number_to_double+48>:	muleq	r3, r12, lr
0x36e8c <number_to_double+52>:	andeq	r6, r3, r12, lsr #29
0x36e90 <number_to_double+56>:	andeq	r6, r3, r0, asr #29
0x36e94 <number_to_double+60>:	andeq	r6, r3, r8, ror #29
0x36e98 <number_to_double+64>:	streqd	r6, [r3], -r8
0x36e9c <number_to_double+68>:	ldr	r3, [r11, -#32]
0x36ea0 <number_to_double+72>:	ldr	r3, [r3, #4]
0x36ea4 <number_to_double+76>:	fltd	f0, r3
0x36ea8 <number_to_double+80>:	b	0x36f1c <number_to_double+196>
0x36eac <number_to_double+84>:	ldr	r0, [r11, -#32]
---Type <return> to continue, or q <return> to quit---

0x36eb0 <number_to_double+88>:	bl	0x35d34 <big_to_double>
0x36eb4 <number_to_double+92>:	stfd	f0, [sp, -#8]!
0x36eb8 <number_to_double+96>:	ldmia	sp!, {r3, r4}
0x36ebc <number_to_double+100>:	b	0x36f1c <number_to_double+196>
0x36ec0 <number_to_double+104>:	ldr	r3, [r11, -#32]
0x36ec4 <number_to_double+108>:	ldr	r0, [r3, #8]
0x36ec8 <number_to_double+112>:	bl	0x36e58 <number_to_double>
0x36ecc <number_to_double+116>:	mvfd	f4, f0
0x36ed0 <number_to_double+120>:	ldr	r3, [r11, -#32]
0x36ed4 <number_to_double+124>:	ldr	r0, [r3, #4]
0x36ed8 <number_to_double+128>:	bl	0x36e58 <number_to_double>
0x36edc <number_to_double+132>:	dvfd	f4, f4, f0
0x36ee0 <number_to_double+136>:	mvfd	f0, f4
0x36ee4 <number_to_double+140>:	b	0x36f1c <number_to_double+196>
0x36ee8 <number_to_double+144>:	ldr	r3, [r11, -#32]
0x36eec <number_to_double+148>:	ldfs	f0, [r3, #4]
0x36ef0 <number_to_double+152>:	mvfd	f0, f0
0x36ef4 <number_to_double+156>:	b	0x36f1c <number_to_double+196>
0x36ef8 <number_to_double+160>:	ldr	r3, [r11, -#32]
0x36efc <number_to_double+164>:	ldmib	r3, {r3, r4}
0x36f00 <number_to_double+168>:	stmdb	sp!, {r3, r4}
0x36f04 <number_to_double+172>:	ldfd	f0, [sp], #8
0x36f08 <number_to_double+176>:	b	0x36f1c <number_to_double+196>
---Type <return> to continue, or q <return> to quit---q
q
Quit
(gdb) hello
i reg f0
i reg f0
f0             0	(raw 0x000000000000000000000000)
(gdb) i reg f4
i reg f4
f4             0	(raw 0x000000000000000000000000)
=============================================================================
#define CLEAR_CACHE do {\
  void *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; \
  register unsigned long _beg __asm ("a1") = (unsigned long)(v);	\
  register unsigned long _end __asm ("a2") = (unsigned long)(ve);\
  register unsigned long _flg __asm ("a3") = 0;			\
  __asm __volatile ("swi 0x9f0002		@ sys_cacheflush"	\
		    : /* no outputs */					\
		    : /* no inputs */					\
		    : "a1");						\
} while (0)

 82c:	e1a03000 	mov	r3, r0
 830:	e3530000 	cmp	r3, #0	; 0x0
 834:	0a00020f 	beq	844 <fasload+0x620>
 838:	e3a03000 	mov	r3, #0	; 0x0
 83c:	e50b3018 	str	r3, [fp, -#24]
 840:	ea000213 	b	854 <fasload+0x630>
 844:	e59f00a8 	ldr	r0, [pc, #168]	; 8f4 <fasload+0x6d0>
 848:	ebfffffe 	bl	0 <round_up>
 84c:	e1a03000 	mov	r3, r0
 850:	e50b3018 	str	r3, [fp, -#24]
 854:	e51b0134 	ldr	r0, [fp, -#308]
 858:	ebfffffe 	bl	0 <round_up>
 85c:	e51b3120 	ldr	r3, [fp, -#288]
 860:	e5933004 	ldr	r3, [r3, #4]
 864:	e50b3154 	str	r3, [fp, -#340]
 868:	e51b3120 	ldr	r3, [fp, -#288]
 86c:	e5932008 	ldr	r2, [r3, #8]
 870:	e51b3154 	ldr	r3, [fp, -#340]
 874:	e0833002 	add	r3, r3, r2
 878:	e50b3158 	str	r3, [fp, -#344]
 87c:	ef9f0002 	swi	0x009f0002
 880:	e51b011c 	ldr	r0, [fp, -#284]
 884:	e51b1120 	ldr	r1, [fp, -#288]
 888:	e51b2018 	ldr	r2, [fp, -#24]
 88c:	e3a03000 	mov	r3, #0	; 0x0
 890:	ebfffffe 	bl	0 <round_up>
 894:	e51b212c 	ldr	r2, [fp, -#300]
 898:	e59f3048 	ldr	r3, [pc, #72]	; 8e8 <fasload+0x6c4>
 89c:	e5832000 	str	r2, [r3]
 8a0:	e51b2130 	ldr	r2, [fp, -#304]
 8a4:	e59f3040 	ldr	r3, [pc, #64]	; 8ec <fasload+0x6c8>
 8a8:	e5832000 	str	r2, [r3]
 8ac:	e59f3094 	ldr	r3, [pc, #148]	; 948 <fasload+0x724>
 8b0:	e5930000 	ldr	r0, [r3]
 8b4:	ebfffffe 	bl	0 <round_up>
 8b8:	e1a02000 	mov	r2, r0
 8bc:	e59f3088 	ldr	r3, [pc, #136]	; 94c <fasload+0x728>
 8c0:	e1520003 	cmp	r2, r3
 8c4:	0a000234 	beq	8d8 <fasload+0x6b4>
 8c8:	e59f0080 	ldr	r0, [pc, #128]	; 950 <fasload+0x72c>
 8cc:	e51b3120 	ldr	r3, [fp, -#288]
=============================================================================

Philip Blundell <pb@nexus.co.uk> writes:

> On Fri, 2002-06-14 at 16:51, Camm Maguire wrote:
> > #define CLEAR_CACHE do {\
> >   void *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; \
> >   for (;v<ve;v+=16)   {   \
> >        register unsigned long _beg __asm ("a1") = (unsigned long)(v);	\
> >        register unsigned long _end __asm ("a2") = (unsigned long)(v+16);\
> >        register unsigned long _flg __asm ("a3") = 0;			\
> >        __asm __volatile ("swi 0x9f0002		@ sys_cacheflush"	\
> > 		    : /* no outputs */					\
> > 		    : /* no inputs */					\
> > 		    : "a1");						\
> >        }\
> 
> You don't need the loop.  The arm sys_cacheflush can be given arbitrary
> regions, it works the cache line size out for itself.
> 
> p.
> 
> 
> _______________________________________________
> 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

Re: [Gcl-devel] Re: Flushing the d-cache (was Re: BFD relocations)

[Philip Blundell]

On Fri, 2002-06-14 at 20:21, Camm Maguire wrote:
> I still see this behavior even if all attempts to flush the data cache
> are removed.  Makes me think that the swi instruction is no working.
> Are there alignment requirements on the arguments?  Why aren't
> a1,a2,a3 shown in the assembly?  I've included the CLEAR_CACHE code
> and its assembly below as well.

Hmm, right, your asm() statement has a bug.  Try this one instead.

 __asm __volatile ("swi 0x9f0002	@ sys_cacheflush"	\
		    : "=r" (_beg)				\
		    : "0" (_beg), "r" (_end), "r"(_flg));	\

p.

Re: Flushing the d-cache (was Re: BFD relocations)

[Andreas Schwab]

Camm Maguire <camm@enhanced.com> writes:

|> m68k:
|> #include <asm/cachectl.h>
|> #define CLEAR_CACHE do {\
|> 	void *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; \
|> 	for (;v<ve;v+=16)   \
|> 		sys_cacheflush(v,FLUSH_SCOPE_LINE,FLUSH_CACHE_DATA,16);\
|> 	} while(0)

The comment from Philip applies here as well: no need for the loop.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Flushing the d-cache (was Re: BFD relocations)

[Richard Zidlicky]

On Fri, Jun 14, 2002 at 11:51:38AM -0400, Camm Maguire wrote:

> 
> m68k:
> #include <asm/cachectl.h>
> #define CLEAR_CACHE do {\
> 	void *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; \
> 	for (;v<ve;v+=16)   \
> 		sys_cacheflush(v,FLUSH_SCOPE_LINE,FLUSH_CACHE_DATA,16);\
> 	} while(0)

dunno what exactly you are tryinig to do but this one will not
guarantee data/instruction cache coherency - use FLUSH_CACHE_BOTH
for that.

Richard

Re: [Gcl-devel] Re: Flushing the d-cache (was Re: BFD relocations)

[Camm Maguire]

Greetings, and thank you all for your suggestions!

m68k now working!  Have so far i386, s390, m68k, powerpc.  Working on
arm,mips.  Haven't started 64bit yet.  As always, any helpful comments
like the below for any remaining (Debian) arches are *most* welcome!

Take care,



Richard Zidlicky <Richard.Zidlicky@stud.informatik.uni-erlangen.de> writes:

> On Fri, Jun 14, 2002 at 11:51:38AM -0400, Camm Maguire wrote:
> 
> > 
> > m68k:
> > #include <asm/cachectl.h>
> > #define CLEAR_CACHE do {\
> > 	void *v=memory->cfd.cfd_start,*ve=v+memory->cfd.cfd_size; \
> > 	for (;v<ve;v+=16)   \
> > 		sys_cacheflush(v,FLUSH_SCOPE_LINE,FLUSH_CACHE_DATA,16);\
> > 	} while(0)
> 
> dunno what exactly you are tryinig to do but this one will not
> guarantee data/instruction cache coherency - use FLUSH_CACHE_BOTH
> for that.
> 
> Richard
> 
> _______________________________________________
> 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

MIPS bfd_get_relocated_section_contents broken

[Camm Maguire]

Greetings!  To summarize the progress thus far,
bfd_get_relocated_section_contents works just fine for relocating and
executing dynamically loaded object files (so far) on

i386
s390
m68k
arm
ppc

at least.  This is for gcl, which works by opening its own binary file
as a bfd, building a hash table of its symbols, then opening objects
to be loaded as bfd's, setting the symbols therein to the values in
the main executable adjusted for the new section vma, and then
performing bfd_get_relocated_section_contents.  The memory image thus
created is then executed, after cache clearing operations.

There are several difficulties with MIPS.  The first seems treatable
-- it is the _gp_disp issue.  I've just added the following snippet to
by symbol redefinition code, and I can at least handle the HI16 and
LO16 reloc types:

In the running program:

  if ((v=bfd_canonicalize_symtab(bself,q))<0)
    FEerror("Cannot canonicalize self's symtab");
  for (u=0;u<v;u++) {
    if (!strcmp(q[u]->name,"_gp_disp")) {
      struct bfd_link_hash_entry *h;
      if (!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,true,true,true)))
	FEerror("Cannot make new hash entry");
      h->type=bfd_link_hash_defined;
      if (!q[u]->section)
	FEerror("Symbol is missing section");
      h->u.def.value=q[u]->value+q[u]->section->vma;
      h->u.def.section=q[u]->section;
    }
  }

For the object to be loaded:

  if ((v=bfd_canonicalize_symtab(b,q))<0)
    FEerror("cannot canonicalize symtab");
  for (u=0;u<v;u++) {

    struct bfd_link_hash_entry *h;

    if (!strncmp("init_",q[u]->name,5)) {
      init_address=q[u]->value;
      continue;
    }

    if (!(h=bfd_link_hash_lookup(link_info.hash,q[u]->name,false,false,true))) 
      continue;

    if (h->type!=bfd_link_hash_defined) 
      FEerror("Undefined symbol");
      
    if (h->u.def.section) {
      q[u]->value=h->u.def.value+h->u.def.section->vma;
      q[u]->flags|=BSF_WEAK;
      if (!strcmp(q[u]->name,"_gp_disp")) {
	q[u]->section=b->sections;
	_bfd_set_gp_value(b,q[u]->value);
      }
    } else 
      FEerror("Symbol without section");

  }


(I need to redefine the section for the _gp_disp symbol in the object
so the bfd routines will lookup the section owner correctly and find
the gp value when _bfd_get_gp_value is called.)


The problem is with R_MIPS_GOT16.  From the comments, it seems as if
this routine was never completed.  The function mips_elf_got16_reloc
just bails completely unless producing relocateable output:

   This implementation suffices for the assembler, but the linker does
   not yet know how to create global offset tables.  */

static bfd_reloc_status_type
mips_elf_got16_reloc (abfd, reloc_entry, symbol, data, input_section,
		      output_bfd, error_message)
     bfd *abfd;
     arelent *reloc_entry;
     asymbol *symbol;
     PTR data;
     asection *input_section;
     bfd *output_bfd;
     char **error_message;
{
  /* If we're relocating, and this an external symbol, we don't want
     to change anything.  */
  if (output_bfd != (bfd *) NULL
      && (symbol->flags & BSF_SECTION_SYM) == 0
      && reloc_entry->addend == 0)
    {
      reloc_entry->address += input_section->output_offset;
      return bfd_reloc_ok;
    }

  /* If we're relocating, and this is a local symbol, we can handle it
     just like HI16.  */
  if (output_bfd != (bfd *) NULL
      && (symbol->flags & BSF_SECTION_SYM) != 0)
    return mips_elf_hi16_reloc (abfd, reloc_entry, symbol, data,
				input_section, output_bfd, error_message);

  abort ();
}

I run into the abort() early on.  I've tried just as a test adding the
following at the top:

  if (output_bfd == (bfd *)NULL)
    output_bfd = symbol->section->output_section->owner;

This gets me past "conventional" symbols, but fails with function
calls (compiled with -mlong-calls), as the section here is the
undefined section.  If I don't compile with -mlong-calls, the function
calls get relocated with a generic routine, (R_MIPS_CALL16), but this
triggers an overflow in my application, as the running section vma's
are all less than the newly loaded object section vma's.

Any suggestions, most appreciated!

Take care,



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

Re: [Gcl-devel] Re: BFD relocations

[Camm Maguire]

Greetings!  

When called to retrieve non-relocatable output (i.e. with the
output_bfd parameter set to 0), bfd_get_relocated_section_contents
works on the following platforms:

elf: i386 ppc s390 m68k arm sparc

The following platforms fail:

elf: mips alpha ia64 hppa
coff: i386

1) Is it intended to support this routine on all platforms eventually?
2) Are patches enabling this function likely to be accepted rather
	easily, or are they likely to break other currently used
	routines? 
3) Are there recommended guidelines for such patches?  I.e. relatively
	safe places for modifications?
4) Are there knowledgeable experts on said systems who can help with
	such patches?

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

Re: [Gcl-devel] Re: BFD relocations

[Alan Modra]

On Sat, Jul 27, 2002 at 12:59:04AM -0400, Camm Maguire wrote:
> Greetings!  
> 
> When called to retrieve non-relocatable output (i.e. with the
> output_bfd parameter set to 0), bfd_get_relocated_section_contents
> works on the following platforms:
> 
> elf: i386 ppc s390 m68k arm sparc
> 
> The following platforms fail:
> 
> elf: mips alpha ia64 hppa
> coff: i386
> 
> 1) Is it intended to support this routine on all platforms eventually?

What itch will it scratch?

> 2) Are patches enabling this function likely to be accepted rather
> 	easily, or are they likely to break other currently used
> 	routines? 

Implementing this function likely won't break anything.

> 3) Are there recommended guidelines for such patches?  I.e. relatively
> 	safe places for modifications?

You'll likely need to implement missing special_function entries for
reloc howto structures.  It may work out easier in some cases to
implement a new get_relocated_section_contents function rather than
trying to use bfd_generic_get_relocated_section_contents.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [Gcl-devel] Re: BFD relocations

[Camm Maguire]

Greetings, and thanks for your reply!

Alan Modra <amodra@bigpond.net.au> writes:

> On Sat, Jul 27, 2002 at 12:59:04AM -0400, Camm Maguire wrote:
> > Greetings!  
> > 
> > When called to retrieve non-relocatable output (i.e. with the
> > output_bfd parameter set to 0), bfd_get_relocated_section_contents
> > works on the following platforms:
> > 
> > elf: i386 ppc s390 m68k arm sparc
> > 
> > The following platforms fail:
> > 
> > elf: mips alpha ia64 hppa
> > coff: i386
> > 
> > 1) Is it intended to support this routine on all platforms eventually?
> 
> What itch will it scratch?
> 

In lisp, one frequently wants to load an object *at a specific
address* into a running program, incorporate the object in the
program's data structures, and execute the object as necessary.  gcl
makes use of this functionality.  Later, when a lisp image is saved,
the loaded objects are automatically incorporated in it.  To my
understanding, this cannot be achieved via dlopen.

> > 2) Are patches enabling this function likely to be accepted rather
> > 	easily, or are they likely to break other currently used
> > 	routines? 
> 
> Implementing this function likely won't break anything.
> 

Great!

> > 3) Are there recommended guidelines for such patches?  I.e. relatively
> > 	safe places for modifications?
> 
> You'll likely need to implement missing special_function entries for
> reloc howto structures.  It may work out easier in some cases to
> implement a new get_relocated_section_contents function rather than
> trying to use bfd_generic_get_relocated_section_contents.
> 

OK.  A standalone get_relocated_section_contents function per arch
seems the way to go.  I was contemplating modifying the lower level
functions on the order of mips_elf_hi16_reloc, etc., but this does
seem more dangerous.  

The way I'd go about this is to follow what ld does in a debugger.  Is
there a better source of information somewhere?

Also, is there a reason why some arches currently work and others
don't?  I.e., is it just oversight thus far due to the fact that no
one uses the get_relocated_section_contents, or are there arch
specific difficulties which make such a function hard on certain
platforms, e.g. the gp_disp, etc.?

Take care,

> -- 
> Alan Modra
> IBM OzLabs - Linux Technology Centre
> 
> _______________________________________________
> 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

Re: [Gcl-devel] Re: BFD relocations

[Alan Modra]

On Sat, Jul 27, 2002 at 12:07:57PM -0400, Camm Maguire wrote:
> > > 3) Are there recommended guidelines for such patches?  I.e. relatively
> > > 	safe places for modifications?
> > 
> > You'll likely need to implement missing special_function entries for
> > reloc howto structures.  It may work out easier in some cases to
> > implement a new get_relocated_section_contents function rather than
> > trying to use bfd_generic_get_relocated_section_contents.
> > 
> 
> OK.  A standalone get_relocated_section_contents function per arch
> seems the way to go.  I was contemplating modifying the lower level
> functions on the order of mips_elf_hi16_reloc, etc., but this does
> seem more dangerous.  

If you can do so, use the lower level functions.  The per-arch
get_relocated_section_contents is really for weird cases.  Hmm, like
mips.  If you can get mips working properly, any other target will be
a breeze.

> The way I'd go about this is to follow what ld does in a debugger.  Is
> there a better source of information somewhere?

Some of the ELF processor supplements are available on the web.
They will help in figuring out how vairous relocations should be
handled.

> Also, is there a reason why some arches currently work and others
> don't?  I.e., is it just oversight thus far due to the fact that no
> one uses the get_relocated_section_contents, or are there arch
> specific difficulties which make such a function hard on certain
> platforms, e.g. the gp_disp, etc.?

Well, ELF RELA targets generally don't need those special_function
handlers in order to have a working assembler, and the linker
relocate_section function is often not any easier to write using
bfd_perform_relocation.  One of the problems is that the howto
functions weren't designed for relocs that depend on the value of
other relocs, or on extraneous data like segment base addresses.
gp relative relocs are easy enough as the gp base is stashed away
in the bfd.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: BFD relocations -- alpha

[Camm Maguire]

Greetings!  OK, I'm starting to work on this a bit, first with the
alpha.  I have a hunch that all I need to do is call _bfd_set_gp_value
on the input bfd with the destination address of the .text section or
some such, and then bfd_get_relocated_section_contents should work.

I would be most grateful if anyone knows ahead of time what this gp
value should be.  It will save me considerable time reading the
sources.

Take care,

Alan Modra <amodra@bigpond.net.au> writes:

> On Sat, Jul 27, 2002 at 12:07:57PM -0400, Camm Maguire wrote:
> > > > 3) Are there recommended guidelines for such patches?  I.e. relatively
> > > > 	safe places for modifications?
> > > 
> > > You'll likely need to implement missing special_function entries for
> > > reloc howto structures.  It may work out easier in some cases to
> > > implement a new get_relocated_section_contents function rather than
> > > trying to use bfd_generic_get_relocated_section_contents.
> > > 
> > 
> > OK.  A standalone get_relocated_section_contents function per arch
> > seems the way to go.  I was contemplating modifying the lower level
> > functions on the order of mips_elf_hi16_reloc, etc., but this does
> > seem more dangerous.  
> 
> If you can do so, use the lower level functions.  The per-arch
> get_relocated_section_contents is really for weird cases.  Hmm, like
> mips.  If you can get mips working properly, any other target will be
> a breeze.
> 
> > The way I'd go about this is to follow what ld does in a debugger.  Is
> > there a better source of information somewhere?
> 
> Some of the ELF processor supplements are available on the web.
> They will help in figuring out how vairous relocations should be
> handled.
> 
> > Also, is there a reason why some arches currently work and others
> > don't?  I.e., is it just oversight thus far due to the fact that no
> > one uses the get_relocated_section_contents, or are there arch
> > specific difficulties which make such a function hard on certain
> > platforms, e.g. the gp_disp, etc.?
> 
> Well, ELF RELA targets generally don't need those special_function
> handlers in order to have a working assembler, and the linker
> relocate_section function is often not any easier to write using
> bfd_perform_relocation.  One of the problems is that the howto
> functions weren't designed for relocs that depend on the value of
> other relocs, or on extraneous data like segment base addresses.
> gp relative relocs are easy enough as the gp base is stashed away
> in the bfd.
> 
> -- 
> Alan Modra
> IBM OzLabs - Linux Technology Centre
> 
> _______________________________________________
> 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

Re: [Gcl-devel] Re: BFD relocations

[Geoff Keating]

> Date: Wed, 5 Jun 2002 19:05:37 -0400
> From: Daniel Jacobowitz <drow@mvista.com>

> > 1) Is it possible to know for sure that a smaller range could be
> >    flushed safely?
> 
> I believe glibc has an "aux" mechanism to convey this.  I don't know
> how it works, though.  Geoff?

The kernel does, in some versions, pass the size of a cache line (8,
16, whatever), but I don't think glibc passes it to userland yet.
There's no way to know which lines don't need flushing.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>