Targetting S12Z

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Targetting S12Z

John Darrington-4
Hello Utility Binners,

I needed an assembler/disassembler for the NXP (formerly Freescale) S12Z CPU
but it seems that binutils doesn't target that processor.  It does however have
a MCHC12 and S12X which are vaguely similar.

The S12Z instruction set has passing resemblence to its ancestors, viz:
68HC12, HCS12, HCS12X, but has a 24 bit linear address space and its register
configuration is somewhat different.

So I started patching the current HEAD ...

The work is not complete, and undoubtably needs effort to make it fit into
the binutils coding standards etc.   I am prepared to put in the necessary
effort to do this.  But first I wanted to :

1.  Find out the likelihood of such a patch being accepted into binutils.

2.  Make sure that nobody was already working on this, so as to avoid
    duplicating effort.

Maybe somebody could advise me on points 1 and 2 above.

I'm also attaching what I've done so far, in case anyone is interested in looking.

J'

--
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


gas-s12z-patches.tar.xz (13K) Download Attachment
signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Targetting S12Z

Fred Cooke
Awesome, good for you. Chances are probably pretty high if you have your
copyright statement in with GNU HQ. :-)

On 7 January 2018 at 20:55, John Darrington <[hidden email]>
wrote:

> Hello Utility Binners,
>
> I needed an assembler/disassembler for the NXP (formerly Freescale) S12Z
> CPU
> but it seems that binutils doesn't target that processor.  It does however
> have
> a MCHC12 and S12X which are vaguely similar.
>
> The S12Z instruction set has passing resemblence to its ancestors, viz:
> 68HC12, HCS12, HCS12X, but has a 24 bit linear address space and its
> register
> configuration is somewhat different.
>
> So I started patching the current HEAD ...
>
> The work is not complete, and undoubtably needs effort to make it fit into
> the binutils coding standards etc.   I am prepared to put in the necessary
> effort to do this.  But first I wanted to :
>
> 1.  Find out the likelihood of such a patch being accepted into binutils.
>
> 2.  Make sure that nobody was already working on this, so as to avoid
>     duplicating effort.
>
> Maybe somebody could advise me on points 1 and 2 above.
>
> I'm also attaching what I've done so far, in case anyone is interested in
> looking.
>
> J'
>
> --
> Avoid eavesdropping.  Send strong encrypted email.
> PGP Public key ID: 1024D/2DE827B3
> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
> See http://sks-keyservers.net or any PGP keyserver for public key.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Targetting S12Z

Nick Clifton
In reply to this post by John Darrington-4
Hi John,

> I needed an assembler/disassembler for the NXP (formerly Freescale) S12Z CPU
> but it seems that binutils doesn't target that processor.  It does however have
> a MCHC12 and S12X which are vaguely similar.

> The work is not complete, and undoubtably needs effort to make it fit into
> the binutils coding standards etc.   I am prepared to put in the necessary
> effort to do this.  But first I wanted to :
>
> 1.  Find out the likelihood of such a patch being accepted into binutils.

We are open to supporting new (or even old) architectures, but there are a few
caveats:

  * You would need to have an FSF Copyright Assignment for the Binutils
    in place before we could accept your contribution.  (I can provide
    you with the necessary application form if you wish).

  * The code you submit should follow the GNU Coding Standards.

  * Ideally the port should include both the assembler *and* the linker.
    Being able to assemble object files but not link them is frustrating
    for users.

  * The port should include some new tests in the assembler testsuite, to
    make sure that assembling and disassembling is working correctly.  If
    you are including a port of the linker as well, then some new linker
    tests would also be appropriate.

  * You should consider whether you are willing to become a maintainer for
    the port.  A port without a maintainer is likely to bit-rot away over
    time, whereas a port with an active maintainer will continue to grow
    and blossom.  (OK, maybe I got a little bit too prosaic there, but I
    hope that you take my meaning).

Cheers
  Nick

PS.  Are details of the S12Z architecture, especially the ISA and ABI, available
  publicly ?  If so, please could you point me at them ?


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Targetting S12Z

John Darrington-4
On Mon, Jan 08, 2018 at 09:14:57AM +0000, Nick Clifton wrote:
     
     > 1.  Find out the likelihood of such a patch being accepted into binutils.
     

Hi Nick,


     We are open to supporting new (or even old) architectures, but there are a few
     caveats:
     
       * You would need to have an FSF Copyright Assignment for the Binutils
         in place before we could accept your contribution.  (I can provide
         you with the necessary application form if you wish).

That is already in place.
     
       * The code you submit should follow the GNU Coding Standards.

ok. (I notice much of the existing code doesn't)
     
       * Ideally the port should include both the assembler *and* the linker.
         Being able to assemble object files but not link them is frustrating
         for users.

Yes.
     
       * The port should include some new tests in the assembler testsuite, to
         make sure that assembling and disassembling is working correctly.  If
         you are including a port of the linker as well, then some new linker
         tests would also be appropriate.

Indeed.   Perhaps someone could give me some hints about how tests are run in
binutils.  When I type "make check" I just get a warning that "runtest" cannot
be found.  I don't know where to get "runtest" or how to install it.
     
       * You should consider whether you are willing to become a maintainer for
         the port.  A port without a maintainer is likely to bit-rot away over
         time, whereas a port with an active maintainer will continue to grow
         and blossom.  (OK, maybe I got a little bit too prosaic there, but I
         hope that you take my meaning).

ok.  Obviously I cannot commit indefinitely to supporting it.  But at least in the
short term I will do so (but first I need to get it working!)

     
     PS.  Are details of the S12Z architecture, especially the ISA and ABI, available
       publicly ?  If so, please could you point me at them ?

The document I am following is at
  https://cache.freescale.com/files/microcontrollers/doc/ref_manual/S12ZCPU_RM_V1.pdf

So far as I'm aware the ABI and ISA is identical to that of the s12x and the HC12S

Regards,

John
     




--
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Targetting S12Z

Nick Clifton
Hi John,

>        * The port should include some new tests in the assembler testsuite, to
>          make sure that assembling and disassembling is working correctly.  If
>          you are including a port of the linker as well, then some new linker
>          tests would also be appropriate.
>
> Indeed.   Perhaps someone could give me some hints about how tests are run in
> binutils.  

Just as you tried.  Change into the relevant sub-directory and run "make check".

As for your port, you may find it easiest to just add some extra files into the
m68k test directories (gas/testsuite/gas/m68k and ld/testsuite/ld-m68k), basing
them on the files that are already there.


> When I type "make check" I just get a warning that "runtest" cannot
> be found.  I don't know where to get "runtest" or how to install it.

It is usually found in the "dejagnu" package.



> The document I am following is at
>   https://cache.freescale.com/files/microcontrollers/doc/ref_manual/S12ZCPU_RM_V1.pdf

Thanks.

Cheers
  Nick




signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Targetting S12Z

John Darrington-4
In reply to this post by Nick Clifton
I think the S12Z target has reached the stage where it could be considered for
committing.  The status is as follows:

* The assembler and disassembler are complete, and have 291 tests.  I consider it to
  be fairly robust.  Probably however error reporting and recovery could be improved.

* The linker works - that is to say it does everthing I wanted it to.  However a rather
  large number of tests (37 to be precise) fail.   To me this is odd, because I haven't
  changed anything in the linker.  Also when I look in detail at these failing tests,
  either a) I can't understand what they are trying to do; or b) I can undestand what
  they are doing, but can't understand why anyone would consider the tested behaviour
  to be desireable.  If someone can enlighten me on any of these that would be great.
  Otherwise, I suggest disabling those tests for this architecture.

* Similarly, there are few objdump tests which are failing for unknown reasons.  Again,
  the tested for behaviour seems odd IMO.

* There are no relaxes (yet).  Various opportunities for relaxation exist and would
  make the linked code somewhat smaller.

* The code follows the GCS at least to the extent that existing binutils code does.

If anyone has both the time and skills to review the code and provide feedback for
the attached patch, that would be great.

J'



On Mon, Jan 08, 2018 at 09:14:57AM +0000, Nick Clifton wrote:
     
     We are open to supporting new (or even old) architectures, but there are a few
     caveats ...
     
       * You would need to have an FSF Copyright Assignment for the Binutils
         in place before we could accept your contribution.  (I can provide
         you with the necessary application form if you wish).
     
       * The code you submit should follow the GNU Coding Standards.
     
       * Ideally the port should include both the assembler *and* the linker.
         Being able to assemble object files but not link them is frustrating
         for users.
     
       * The port should include some new tests in the assembler testsuite, to
         make sure that assembling and disassembling is working correctly.  If
         you are including a port of the linker as well, then some new linker
         tests would also be appropriate.
     
       * You should consider whether you are willing to become a maintainer for
         the port.  A port without a maintainer is likely to bit-rot away over
         time, whereas a port with an active maintainer will continue to grow
         and blossom.  (OK, maybe I got a little bit too prosaic there, but I
         hope that you take my meaning).
     
     Cheers
       Nick
     
     PS.  Are details of the S12Z architecture, especially the ISA and ABI, available
       publicly ?  If so, please could you point me at them ?
     




--
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


0001-Add-target-S12Z.patch (383K) Download Attachment
signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Targetting S12Z

Nick Clifton
Hi John,

> I think the S12Z target has reached the stage where it could be considered for
> committing.

That is great news.


> * The linker works - that is to say it does everthing I wanted it to.  However a rather
>   large number of tests (37 to be precise) fail.   To me this is odd, because I haven't
>   changed anything in the linker.  Also when I look in detail at these failing tests,
>   either a) I can't understand what they are trying to do; or b) I can undestand what
>   they are doing, but can't understand why anyone would consider the tested behaviour
>   to be desireable.

Which tests fall into these categories ?


> * Similarly, there are few objdump tests which are failing for unknown reasons.  Again,
>   the tested for behaviour seems odd IMO.

Which ones in particular ?


I have glanced over the code and it looks OK to me.  I am going to try it out locally
and see if it raises any problems.  If so I will post again.

Cheers
  Nick


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Targetting S12Z

Nick Clifton
Hi John,

> I think the S12Z target has reached the stage where it could be considered for
> committing.

I am having problems compiling these sources.  For example:
 bfd/elf32-s12z.c: In function 'shift_addend_reloc':
bfd/elf32-s12z.c:37:73: error: unused parameter 'symbol' [-Werror=unused-parameter]
bfd/elf32-s12z.c:38:11: error: unused parameter 'data' [-Werror=unused-parameter]
bfd/elf32-s12z.c:38:27: error: unused parameter 'input_section' [-Werror=unused-parameter]
bfd/elf32-s12z.c:38:47: error: unused parameter 'output' [-Werror=unused-parameter]
bfd/elf32-s12z.c:38:62: error: unused parameter 'msg' [-Werror=unused-parameter]
bfd/elf32-s12z.c: In function 's12z_elf_build_one_stub':
bfd/elf32-s12z.c:262:33: error: unused variable 'phys_addr' [-Werror=unused-variable]
bfd/elf32-s12z.c:262:22: error: unused variable 'phys_page' [-Werror=unused-variable]
bfd/elf32-s12z.c:262:11: error: unused variable 'sym_value' [-Werror=unused-variable]
bfd/elf32-s12z.c:261:13: error: unused variable 'loc' [-Werror=unused-variable]
bfd/elf32-s12z.c:260:8: error: unused variable 'stub_bfd' [-Werror=unused-variable]
bfd/elf32-s12z.c:259:13: error: unused variable 'stub_sec' [-Werror=unused-variable]
bfd/elf32-s12z.c:258:36: error: unused variable 'htab' [-Werror=unused-variable]
bfd/elf32-s12z.c:257:25: error: variable 'info' set but not used [-Werror=unused-but-set-variable]
bfd/elf32-s12z.c:256:38: error: variable 'stub_entry' set but not used [-Werror=unused-but-set-variable]
bfd/elf32-s12z.c: In function 's12z_elf_size_one_stub':
bfd/elf32-s12z.c:278:48: error: unused parameter 'gen_entry' [-Werror=unused-parameter]
bfd/elf32-s12z.c: In function 's12z_elf_bfd_link_hash_table_create':
bfd/elf32-s12z.c:288:43: error: unused parameter 'abfd' [-Werror=unused-parameter]
bfd/elf32-s12z.c: In function 's12z_elf_set_mach_from_flags':
bfd/elf32-s12z.c:297:12: error: unused variable 'flags' [-Werror=unused-variable]
At top level:
bfd/elf32-s12z.c:288:1: error: 's12z_elf_bfd_link_hash_table_create' defined but not used [-Werror=unused-function]
bfd/elf32-s12z.c:278:1: error: 's12z_elf_size_one_stub' defined but not used [-Werror=unused-function]
bfd/elf32-s12z.c:253:1: error: 's12z_elf_build_one_stub' defined but not used [-Werror=unused-function]

And:

opcodes/s12z-dis.c: In function 'decode_possible_symbol':
opcodes/s12z-dis.c:365:46: error: format '%d' expects argument of type 'int', but argument 3 has type 'bfd_vma {aka long unsigned int}' [-Werror=format=]

Cheers
  Nick

 


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Targetting S12Z

John Darrington-4
I wasn't compiling with -Werror.   I think all those warnings can be safely ignored
(except perhaps the last one - I will look into it).    In fact, the functions where
the others occur, I belive are all stubs, and can probably be deleted.  I had copied them
from other targets, but their purpose is unknown (to me).

J'


On Thu, May 17, 2018 at 10:48:12AM +0100, Nick Clifton wrote:
     Hi John,
     
     > I think the S12Z target has reached the stage where it could be considered for
     > committing.
     
     I am having problems compiling these sources.  For example:
      bfd/elf32-s12z.c: In function 'shift_addend_reloc':
     bfd/elf32-s12z.c:37:73: error: unused parameter 'symbol' [-Werror=unused-parameter]
     bfd/elf32-s12z.c:38:11: error: unused parameter 'data' [-Werror=unused-parameter]
     bfd/elf32-s12z.c:38:27: error: unused parameter 'input_section' [-Werror=unused-parameter]
     bfd/elf32-s12z.c:38:47: error: unused parameter 'output' [-Werror=unused-parameter]
     bfd/elf32-s12z.c:38:62: error: unused parameter 'msg' [-Werror=unused-parameter]
     bfd/elf32-s12z.c: In function 's12z_elf_build_one_stub':
     bfd/elf32-s12z.c:262:33: error: unused variable 'phys_addr' [-Werror=unused-variable]
     bfd/elf32-s12z.c:262:22: error: unused variable 'phys_page' [-Werror=unused-variable]
     bfd/elf32-s12z.c:262:11: error: unused variable 'sym_value' [-Werror=unused-variable]
     bfd/elf32-s12z.c:261:13: error: unused variable 'loc' [-Werror=unused-variable]
     bfd/elf32-s12z.c:260:8: error: unused variable 'stub_bfd' [-Werror=unused-variable]
     bfd/elf32-s12z.c:259:13: error: unused variable 'stub_sec' [-Werror=unused-variable]
     bfd/elf32-s12z.c:258:36: error: unused variable 'htab' [-Werror=unused-variable]
     bfd/elf32-s12z.c:257:25: error: variable 'info' set but not used [-Werror=unused-but-set-variable]
     bfd/elf32-s12z.c:256:38: error: variable 'stub_entry' set but not used [-Werror=unused-but-set-variable]
     bfd/elf32-s12z.c: In function 's12z_elf_size_one_stub':
     bfd/elf32-s12z.c:278:48: error: unused parameter 'gen_entry' [-Werror=unused-parameter]
     bfd/elf32-s12z.c: In function 's12z_elf_bfd_link_hash_table_create':
     bfd/elf32-s12z.c:288:43: error: unused parameter 'abfd' [-Werror=unused-parameter]
     bfd/elf32-s12z.c: In function 's12z_elf_set_mach_from_flags':
     bfd/elf32-s12z.c:297:12: error: unused variable 'flags' [-Werror=unused-variable]
     At top level:
     bfd/elf32-s12z.c:288:1: error: 's12z_elf_bfd_link_hash_table_create' defined but not used [-Werror=unused-function]
     bfd/elf32-s12z.c:278:1: error: 's12z_elf_size_one_stub' defined but not used [-Werror=unused-function]
     bfd/elf32-s12z.c:253:1: error: 's12z_elf_build_one_stub' defined but not used [-Werror=unused-function]
     
     And:
     
     opcodes/s12z-dis.c: In function 'decode_possible_symbol':
     opcodes/s12z-dis.c:365:46: error: format '%d' expects argument of type 'int', but argument 3 has type 'bfd_vma {aka long unsigned int}' [-Werror=format=]
     
     Cheers
       Nick
     
       
     




--
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Targetting S12Z

Nick Clifton
Hi John,

> I wasn't compiling with -Werror.

Please do.  That is standard for the binutils sources these days, and it
helps to keep the code extra squeaky clean.

Cheers
  Nick


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[PATCH 1/2] Fix print format warning.

John Darrington-4
* opcodes/s12z-dis.c (decode_possible_symbol): Use BFD_VMA_FMT to correctly
  print an address.
---
 opcodes/s12z-dis.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/opcodes/s12z-dis.c b/opcodes/s12z-dis.c
index 11f01a1..4512311 100644
--- a/opcodes/s12z-dis.c
+++ b/opcodes/s12z-dis.c
@@ -362,7 +362,7 @@ decode_possible_symbol (bfd_vma addr, struct disassemble_info *info)
 {
   if (!info->symbol_at_address_func (addr, info))
     {
-      (*info->fprintf_func) (info->stream, "%d", addr);
+      (*info->fprintf_func) (info->stream, "%" BFD_VMA_FMT "d", addr);
     }
   else
     {
--
2.1.4

Reply | Threaded
Open this post in threaded view
|

[PATCH 2/2] S12Z: Avoid compiler warnings.

John Darrington-4
* bfd/elf32-s12z.c: delete unused functions, and mark unused parameters with
 appropriate attribute.
---
 bfd/elf32-s12z.c | 59 +++-----------------------------------------------------
 1 file changed, 3 insertions(+), 56 deletions(-)

diff --git a/bfd/elf32-s12z.c b/bfd/elf32-s12z.c
index 123b2d6..0753d1b 100644
--- a/bfd/elf32-s12z.c
+++ b/bfd/elf32-s12z.c
@@ -34,8 +34,9 @@ static bfd_boolean s12z_info_to_howto_rel
   (bfd *, arelent *, Elf_Internal_Rela *);
 
 static bfd_reloc_status_type
-shift_addend_reloc (bfd *abfd, arelent *reloc_entry, struct bfd_symbol *symbol,
-  void *data, asection *input_section, bfd *output, char **msg)
+shift_addend_reloc (bfd *abfd, arelent *reloc_entry, struct bfd_symbol *symbol ATTRIBUTE_UNUSED,
+    void *data ATTRIBUTE_UNUSED, asection *input_section ATTRIBUTE_UNUSED,
+    bfd *output ATTRIBUTE_UNUSED, char **msg ATTRIBUTE_UNUSED)
 {
   /* This is a really peculiar reloc, which is done for compatibility
      with the Freescale toolchain.
@@ -248,53 +249,12 @@ s12z_info_to_howto_rel (bfd *abfd,
 
 /* Far trampoline generation.  */
 
-/* Build a S12Z trampoline stub.  */
-static bfd_boolean
-s12z_elf_build_one_stub (struct bfd_hash_entry *gen_entry, void *in_arg)
-{
-  printf ("%s:%d %s\n", __FILE__, __LINE__, __FUNCTION__);
-  struct elf32_s12z_stub_hash_entry *stub_entry;
-  struct bfd_link_info *info;
-  struct s12z_elf_link_hash_table *htab;
-  asection *stub_sec;
-  bfd *stub_bfd;
-  bfd_byte *loc;
-  bfd_vma sym_value, phys_page, phys_addr;
-
-  /* Massage our args to the form they really have.  */
-  stub_entry = (struct elf32_s12z_stub_hash_entry *) gen_entry;
-  info = (struct bfd_link_info *) in_arg;
-
-  //  htab = s12z_elf_hash_table (info);
-
-
-  return TRUE;
-}
-
-/* As above, but don't actually build the stub.  Just bump offset so
-   we know stub section sizes.  */
-
-static bfd_boolean
-s12z_elf_size_one_stub (struct bfd_hash_entry *gen_entry,
-   void *in_arg ATTRIBUTE_UNUSED)
-{
-  printf ("%s:%d %s\n", __FILE__, __LINE__, __FUNCTION__);
-  return TRUE;
-}
-
 /* Create a S12Z ELF linker hash table.  */
 
-static struct bfd_link_hash_table *
-s12z_elf_bfd_link_hash_table_create (bfd *abfd)
-{
-  printf ("%s:%d %s\n", __FILE__, __LINE__, __FUNCTION__);
-  return NULL;
-}
 
 static bfd_boolean
 s12z_elf_set_mach_from_flags (bfd *abfd)
 {
-  flagword flags = elf_elfheader (abfd)->e_flags;
   bfd_default_set_arch_mach (abfd, bfd_arch_s12z, 0); // bfd_mach_s12z);
 
   return TRUE;
@@ -311,21 +271,8 @@ s12z_elf_set_mach_from_flags (bfd *abfd)
 
 #define elf_info_to_howto 0
 #define elf_info_to_howto_rel s12z_info_to_howto_rel
-//#define elf_backend_check_relocs     elf32_s12z_check_relocs
-//#define elf_backend_relocate_section elf32_s12z_relocate_section
 #define elf_backend_object_p s12z_elf_set_mach_from_flags
 #define elf_backend_final_write_processing 0
 #define elf_backend_can_gc_sections 1
-/* #define elf_backend_post_process_headers     elf32_s12z_post_process_headers */
-/* #define elf_backend_add_symbol_hook  elf32_s12z_add_symbol_hook */
-/* #define elf_backend_merge_symbol_attribute elf32_s12z_merge_symbol_attribute */
-
-/* #define bfd_elf32_bfd_link_hash_table_create \ */
-/* s12z_elf_bfd_link_hash_table_create */
-/* #define bfd_elf32_bfd_merge_private_bfd_data \ */
-/* _bfd_s12z_elf_merge_private_bfd_data */
-/* #define bfd_elf32_bfd_set_private_flags _bfd_s12z_elf_set_private_flags */
-/* #define bfd_elf32_bfd_print_private_bfd_data \ */
-/* _bfd_s12z_elf_print_private_bfd_data */
 
 #include "elf32-target.h"
--
2.1.4

Reply | Threaded
Open this post in threaded view
|

Re: Targetting S12Z

Nick Clifton
In reply to this post by John Darrington-4
Hi John,

> I think the S12Z target has reached the stage where it could be considered for
> committing.  The status is as follows:

Right - I have applied your patches and committed them to the repository.

I think that there is something funny going on with how the s12z assembler
handles symbols, and that this is causing the strange linker and binutils
testsuite failures.  I have not had time to dig into it however, so I am
going to leave it with you... :-)

Cheers
  Nick



signature.asc (849 bytes) Download Attachment