* BFD relocations @ 2002-06-02 20:42 Camm Maguire 2002-06-02 22:06 ` Daniel Jacobowitz 0 siblings, 1 reply; 33+ messages in thread From: Camm Maguire @ 2002-06-02 20:42 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: BFD relocations 2002-06-02 20:42 BFD relocations Camm Maguire @ 2002-06-02 22:06 ` Daniel Jacobowitz 2002-06-03 15:08 ` Camm Maguire 0 siblings, 1 reply; 33+ messages in thread From: Daniel Jacobowitz @ 2002-06-02 22:06 UTC (permalink / raw) To: Camm Maguire; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: BFD relocations 2002-06-02 22:06 ` Daniel Jacobowitz @ 2002-06-03 15:08 ` Camm Maguire 2002-06-03 15:29 ` Daniel Jacobowitz 0 siblings, 1 reply; 33+ messages in thread From: Camm Maguire @ 2002-06-03 15:08 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: BFD relocations 2002-06-03 15:08 ` Camm Maguire @ 2002-06-03 15:29 ` Daniel Jacobowitz 2002-06-04 14:34 ` [Gcl-devel] " Camm Maguire 0 siblings, 1 reply; 33+ messages in thread From: Daniel Jacobowitz @ 2002-06-03 15:29 UTC (permalink / raw) To: Camm Maguire; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-03 15:29 ` Daniel Jacobowitz @ 2002-06-04 14:34 ` Camm Maguire 2002-06-04 14:42 ` Geoff Keating 2002-06-04 14:44 ` Daniel Jacobowitz 0 siblings, 2 replies; 33+ messages in thread From: Camm Maguire @ 2002-06-04 14:34 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-04 14:34 ` [Gcl-devel] " Camm Maguire @ 2002-06-04 14:42 ` Geoff Keating 2002-06-04 14:44 ` Daniel Jacobowitz 1 sibling, 0 replies; 33+ messages in thread From: Geoff Keating @ 2002-06-04 14:42 UTC (permalink / raw) To: camm; +Cc: drow, binutils, gcl-devel > 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> ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-04 14:34 ` [Gcl-devel] " Camm Maguire 2002-06-04 14:42 ` Geoff Keating @ 2002-06-04 14:44 ` Daniel Jacobowitz 2002-06-04 15:06 ` Camm Maguire 1 sibling, 1 reply; 33+ messages in thread From: Daniel Jacobowitz @ 2002-06-04 14:44 UTC (permalink / raw) To: Camm Maguire; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-04 14:44 ` Daniel Jacobowitz @ 2002-06-04 15:06 ` Camm Maguire 2002-06-04 15:33 ` Daniel Jacobowitz 0 siblings, 1 reply; 33+ messages in thread From: Camm Maguire @ 2002-06-04 15:06 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-04 15:06 ` Camm Maguire @ 2002-06-04 15:33 ` Daniel Jacobowitz 2002-06-05 16:03 ` Camm Maguire 0 siblings, 1 reply; 33+ messages in thread From: Daniel Jacobowitz @ 2002-06-04 15:33 UTC (permalink / raw) To: Camm Maguire; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-04 15:33 ` Daniel Jacobowitz @ 2002-06-05 16:03 ` Camm Maguire 2002-06-05 16:09 ` Daniel Jacobowitz 0 siblings, 1 reply; 33+ messages in thread From: Camm Maguire @ 2002-06-05 16:03 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-05 16:03 ` Camm Maguire @ 2002-06-05 16:09 ` Daniel Jacobowitz 2002-06-05 17:21 ` Camm Maguire 2002-06-05 20:09 ` [Gcl-devel] Re: BFD relocations Geoff Keating 0 siblings, 2 replies; 33+ messages in thread From: Daniel Jacobowitz @ 2002-06-05 16:09 UTC (permalink / raw) To: Camm Maguire; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-05 16:09 ` Daniel Jacobowitz @ 2002-06-05 17:21 ` Camm Maguire 2002-06-05 18:13 ` Daniel Jacobowitz 2002-06-05 20:09 ` [Gcl-devel] Re: BFD relocations Geoff Keating 1 sibling, 1 reply; 33+ messages in thread From: Camm Maguire @ 2002-06-05 17:21 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-05 17:21 ` Camm Maguire @ 2002-06-05 18:13 ` Daniel Jacobowitz 2002-06-06 20:14 ` Camm Maguire 0 siblings, 1 reply; 33+ messages in thread From: Daniel Jacobowitz @ 2002-06-05 18:13 UTC (permalink / raw) To: Camm Maguire; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-05 18:13 ` Daniel Jacobowitz @ 2002-06-06 20:14 ` Camm Maguire 2002-06-06 21:00 ` Daniel Jacobowitz 2002-06-07 6:55 ` Paul Koning 0 siblings, 2 replies; 33+ messages in thread From: Camm Maguire @ 2002-06-06 20:14 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-06 20:14 ` Camm Maguire @ 2002-06-06 21:00 ` Daniel Jacobowitz 2002-06-06 22:03 ` Jason R Thorpe 2002-06-07 6:55 ` Paul Koning 1 sibling, 1 reply; 33+ messages in thread From: Daniel Jacobowitz @ 2002-06-06 21:00 UTC (permalink / raw) To: Camm Maguire; +Cc: binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-06 21:00 ` Daniel Jacobowitz @ 2002-06-06 22:03 ` Jason R Thorpe 0 siblings, 0 replies; 33+ messages in thread From: Jason R Thorpe @ 2002-06-06 22:03 UTC (permalink / raw) To: Camm Maguire, binutils, gcl-devel 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> ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-06 20:14 ` Camm Maguire 2002-06-06 21:00 ` Daniel Jacobowitz @ 2002-06-07 6:55 ` Paul Koning 2002-06-10 15:35 ` Camm Maguire 1 sibling, 1 reply; 33+ messages in thread From: Paul Koning @ 2002-06-07 6:55 UTC (permalink / raw) To: camm; +Cc: drow, binutils, gcl-devel > 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-07 6:55 ` Paul Koning @ 2002-06-10 15:35 ` Camm Maguire 2002-06-10 16:10 ` Daniel Jacobowitz 0 siblings, 1 reply; 33+ messages in thread From: Camm Maguire @ 2002-06-10 15:35 UTC (permalink / raw) To: Paul Koning; +Cc: drow, binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-10 15:35 ` Camm Maguire @ 2002-06-10 16:10 ` Daniel Jacobowitz 2002-06-14 8:51 ` Flushing the d-cache (was Re: BFD relocations) Camm Maguire ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: Daniel Jacobowitz @ 2002-06-10 16:10 UTC (permalink / raw) To: Camm Maguire; +Cc: Paul Koning, binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Flushing the d-cache (was Re: BFD relocations) 2002-06-10 16:10 ` Daniel Jacobowitz @ 2002-06-14 8:51 ` Camm Maguire 2002-06-14 9:16 ` Philip Blundell ` (2 more replies) 2002-06-19 11:25 ` MIPS bfd_get_relocated_section_contents broken Camm Maguire 2002-07-27 0:06 ` [Gcl-devel] Re: BFD relocations Camm Maguire 2 siblings, 3 replies; 33+ messages in thread From: Camm Maguire @ 2002-06-14 8:51 UTC (permalink / raw) To: Daniel Jacobowitz Cc: Paul Koning, binutils, gcl-devel, roman, debian-68k, pb, debian-arm 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Flushing the d-cache (was Re: BFD relocations) 2002-06-14 8:51 ` Flushing the d-cache (was Re: BFD relocations) Camm Maguire @ 2002-06-14 9:16 ` Philip Blundell 2002-06-14 12:22 ` [Gcl-devel] " Camm Maguire 2002-06-14 13:10 ` Andreas Schwab 2002-06-17 15:37 ` Richard Zidlicky 2 siblings, 1 reply; 33+ messages in thread From: Philip Blundell @ 2002-06-14 9:16 UTC (permalink / raw) To: Camm Maguire Cc: Daniel Jacobowitz, Paul Koning, binutils, gcl-devel, roman, debian-68k, debian-arm 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: Flushing the d-cache (was Re: BFD relocations) 2002-06-14 9:16 ` Philip Blundell @ 2002-06-14 12:22 ` Camm Maguire 2002-06-14 12:34 ` Philip Blundell 0 siblings, 1 reply; 33+ messages in thread From: Camm Maguire @ 2002-06-14 12:22 UTC (permalink / raw) To: Philip Blundell Cc: Daniel Jacobowitz, Paul Koning, binutils, gcl-devel, debian-arm 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: Flushing the d-cache (was Re: BFD relocations) 2002-06-14 12:22 ` [Gcl-devel] " Camm Maguire @ 2002-06-14 12:34 ` Philip Blundell 0 siblings, 0 replies; 33+ messages in thread From: Philip Blundell @ 2002-06-14 12:34 UTC (permalink / raw) To: Camm Maguire Cc: Daniel Jacobowitz, Paul Koning, binutils, gcl-devel, debian-arm 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Flushing the d-cache (was Re: BFD relocations) 2002-06-14 8:51 ` Flushing the d-cache (was Re: BFD relocations) Camm Maguire 2002-06-14 9:16 ` Philip Blundell @ 2002-06-14 13:10 ` Andreas Schwab 2002-06-17 15:37 ` Richard Zidlicky 2 siblings, 0 replies; 33+ messages in thread From: Andreas Schwab @ 2002-06-14 13:10 UTC (permalink / raw) To: Camm Maguire Cc: Daniel Jacobowitz, Paul Koning, binutils, gcl-devel, roman, debian-68k, pb, debian-arm 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." ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Flushing the d-cache (was Re: BFD relocations) 2002-06-14 8:51 ` Flushing the d-cache (was Re: BFD relocations) Camm Maguire 2002-06-14 9:16 ` Philip Blundell 2002-06-14 13:10 ` Andreas Schwab @ 2002-06-17 15:37 ` Richard Zidlicky 2002-06-17 20:09 ` [Gcl-devel] " Camm Maguire 2 siblings, 1 reply; 33+ messages in thread From: Richard Zidlicky @ 2002-06-17 15:37 UTC (permalink / raw) To: Camm Maguire Cc: Daniel Jacobowitz, Paul Koning, binutils, gcl-devel, roman, debian-68k, pb, debian-arm 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: Flushing the d-cache (was Re: BFD relocations) 2002-06-17 15:37 ` Richard Zidlicky @ 2002-06-17 20:09 ` Camm Maguire 0 siblings, 0 replies; 33+ messages in thread From: Camm Maguire @ 2002-06-17 20:09 UTC (permalink / raw) To: Richard Zidlicky Cc: Daniel Jacobowitz, Paul Koning, binutils, gcl-devel, roman, debian-68k, pb, debian-arm 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* MIPS bfd_get_relocated_section_contents broken 2002-06-10 16:10 ` Daniel Jacobowitz 2002-06-14 8:51 ` Flushing the d-cache (was Re: BFD relocations) Camm Maguire @ 2002-06-19 11:25 ` Camm Maguire 2002-07-27 0:06 ` [Gcl-devel] Re: BFD relocations Camm Maguire 2 siblings, 0 replies; 33+ messages in thread From: Camm Maguire @ 2002-06-19 11:25 UTC (permalink / raw) To: Daniel Jacobowitz Cc: Paul Koning, binutils, gcl-devel, debian-mips, Ryan Murray 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-10 16:10 ` Daniel Jacobowitz 2002-06-14 8:51 ` Flushing the d-cache (was Re: BFD relocations) Camm Maguire 2002-06-19 11:25 ` MIPS bfd_get_relocated_section_contents broken Camm Maguire @ 2002-07-27 0:06 ` Camm Maguire 2002-07-27 9:08 ` Alan Modra 2 siblings, 1 reply; 33+ messages in thread From: Camm Maguire @ 2002-07-27 0:06 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Paul Koning, binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-07-27 0:06 ` [Gcl-devel] Re: BFD relocations Camm Maguire @ 2002-07-27 9:08 ` Alan Modra 2002-07-27 12:23 ` Camm Maguire 0 siblings, 1 reply; 33+ messages in thread From: Alan Modra @ 2002-07-27 9:08 UTC (permalink / raw) To: Camm Maguire; +Cc: Daniel Jacobowitz, Paul Koning, binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-07-27 9:08 ` Alan Modra @ 2002-07-27 12:23 ` Camm Maguire 2002-07-30 0:46 ` Alan Modra 0 siblings, 1 reply; 33+ messages in thread From: Camm Maguire @ 2002-07-27 12:23 UTC (permalink / raw) To: Alan Modra; +Cc: Daniel Jacobowitz, Paul Koning, binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-07-27 12:23 ` Camm Maguire @ 2002-07-30 0:46 ` Alan Modra 2002-08-11 9:26 ` BFD relocations -- alpha Camm Maguire 0 siblings, 1 reply; 33+ messages in thread From: Alan Modra @ 2002-07-30 0:46 UTC (permalink / raw) To: Camm Maguire; +Cc: Daniel Jacobowitz, Paul Koning, binutils, gcl-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: BFD relocations -- alpha 2002-07-30 0:46 ` Alan Modra @ 2002-08-11 9:26 ` Camm Maguire 0 siblings, 0 replies; 33+ messages in thread From: Camm Maguire @ 2002-08-11 9:26 UTC (permalink / raw) To: Alan Modra Cc: Daniel Jacobowitz, Paul Koning, binutils, gcl-devel, debian-alpha 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Gcl-devel] Re: BFD relocations 2002-06-05 16:09 ` Daniel Jacobowitz 2002-06-05 17:21 ` Camm Maguire @ 2002-06-05 20:09 ` Geoff Keating 1 sibling, 0 replies; 33+ messages in thread From: Geoff Keating @ 2002-06-05 20:09 UTC (permalink / raw) To: drow; +Cc: camm, binutils, gcl-devel > 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> ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2002-08-11 16:26 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-02 20:42 BFD relocations Camm Maguire 2002-06-02 22:06 ` Daniel Jacobowitz 2002-06-03 15:08 ` Camm Maguire 2002-06-03 15:29 ` Daniel Jacobowitz 2002-06-04 14:34 ` [Gcl-devel] " Camm Maguire 2002-06-04 14:42 ` Geoff Keating 2002-06-04 14:44 ` Daniel Jacobowitz 2002-06-04 15:06 ` Camm Maguire 2002-06-04 15:33 ` Daniel Jacobowitz 2002-06-05 16:03 ` Camm Maguire 2002-06-05 16:09 ` Daniel Jacobowitz 2002-06-05 17:21 ` Camm Maguire 2002-06-05 18:13 ` Daniel Jacobowitz 2002-06-06 20:14 ` Camm Maguire 2002-06-06 21:00 ` Daniel Jacobowitz 2002-06-06 22:03 ` Jason R Thorpe 2002-06-07 6:55 ` Paul Koning 2002-06-10 15:35 ` Camm Maguire 2002-06-10 16:10 ` Daniel Jacobowitz 2002-06-14 8:51 ` Flushing the d-cache (was Re: BFD relocations) Camm Maguire 2002-06-14 9:16 ` Philip Blundell 2002-06-14 12:22 ` [Gcl-devel] " Camm Maguire 2002-06-14 12:34 ` Philip Blundell 2002-06-14 13:10 ` Andreas Schwab 2002-06-17 15:37 ` Richard Zidlicky 2002-06-17 20:09 ` [Gcl-devel] " Camm Maguire 2002-06-19 11:25 ` MIPS bfd_get_relocated_section_contents broken Camm Maguire 2002-07-27 0:06 ` [Gcl-devel] Re: BFD relocations Camm Maguire 2002-07-27 9:08 ` Alan Modra 2002-07-27 12:23 ` Camm Maguire 2002-07-30 0:46 ` Alan Modra 2002-08-11 9:26 ` BFD relocations -- alpha Camm Maguire 2002-06-05 20:09 ` [Gcl-devel] Re: BFD relocations Geoff Keating
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).