Re: New Sanyo Stormy16 relocations

Re: New Sanyo Stormy16 relocations

[DJ Delorie]

I'm committing this approved patch on Andrew's behalf.  The cgen parts
were approved by FChE off-list.

> bfd/ChangeLog
> 	* elf32-xstormy16.c (xstormy16_elf_howto): Add R_XSTORMY16_LO16
> 	and R_XSTORMY16_HI16) howto entries.
> 	(xstormy16_reloc_map): Map R_XSTORMY16_{LO,HI}16 to BFD_RELOC_{LO,HI}16.
> 	(xstormy16_info_to_howto_rela): Use R_XSTORMY16_GNU_VTINHERIT to 
> 	determine the start of the second reloc table.
> 
> cgen/ChangeLog
> 	* cpu/xstormy16.cpu (imm16): Call handler immediate16.
> 	* cpu/xstormy16.opc (parse_small_immediate): Return on '@'.
> 	(parse_immediate16): Handle immediate16 values, which now include
> 	@hi(label) and @lo(label)
> 
> gas/ChangeLog
> 	* config/tc-xstormy16.c (md_cgen_lookup_reloc): If a relocation 
> 	has already been set up, use it.
> 
> include/ChangeLog
> 	* elf/xstormy16.h (START_RELOC_NUMBERS) Add relocation numbers
> 	for R_XSTORMY16_LO16 and R_XSTORMY16_HI16.
> 
> opcodes/ChangeLog
> 	* opcodes/xstormy16-asm.c: Regenerate.

Re: New Sanyo Stormy16 relocations

[Alan Modra]

On Mon, Dec 16, 2002 at 10:53:09PM -0500, DJ Delorie wrote:
> > 	* cpu/xstormy16.opc (parse_small_immediate): Return on '@'.
> > 	(parse_immediate16): Handle immediate16 values, which now include
> > 	@hi(label) and @lo(label)

xstormy16-asm.c:133: warning: function declaration isn't a prototype

Please fix.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: New Sanyo Stormy16 relocations

[DJ Delorie]

> xstormy16-asm.c:133: warning: function declaration isn't a prototype
> 
> Please fix.

Fixed.

2002-12-16  DJ Delorie  <dj@delorie.com>

	* cpu/xstormy16.opc (parse_immediate16): Add prototype.

Index: cpu/xstormy16.opc
===================================================================
RCS file: /cvs/src/src/cgen/cpu/xstormy16.opc,v
retrieving revision 1.3
diff -p -3 -r1.3 xstormy16.opc
*** cpu/xstormy16.opc	17 Dec 2002 03:54:41 -0000	1.3
--- cpu/xstormy16.opc	17 Dec 2002 04:47:25 -0000
*************** static const char * parse_mem8
*** 34,39 ****
--- 34,41 ----
    PARAMS ((CGEN_CPU_DESC, const char **, int, unsigned long *));
  static const char * parse_small_immediate
    PARAMS ((CGEN_CPU_DESC, const char **, int, unsigned long *));
+ static const char * parse_immediate16
+   PARAMS ((CGEN_CPU_DESC, const char **, int, unsigned long *));
  
  /* The machine-independent code doesn't know how to disambiguate
       mov (foo),r3

2002-12-16  DJ Delorie  <dj@delorie.com>

	* xstormy16-asm.c (parse_immediate16): Add prototype.

Index: xstormy16-asm.c
===================================================================
RCS file: /cvs/src/src/opcodes/xstormy16-asm.c,v
retrieving revision 1.5
diff -p -3 -r1.5 xstormy16-asm.c
*** xstormy16-asm.c	17 Dec 2002 03:57:49 -0000	1.5
--- xstormy16-asm.c	17 Dec 2002 04:47:45 -0000
*************** static const char * parse_mem8
*** 52,57 ****
--- 52,59 ----
    PARAMS ((CGEN_CPU_DESC, const char **, int, unsigned long *));
  static const char * parse_small_immediate
    PARAMS ((CGEN_CPU_DESC, const char **, int, unsigned long *));
+ static const char * parse_immediate16
+   PARAMS ((CGEN_CPU_DESC, const char **, int, unsigned long *));
  
  /* The machine-independent code doesn't know how to disambiguate
       mov (foo),r3

Re: New Sanyo Stormy16 relocations

[Doug Evans]

DJ Delorie writes:
 > I'm committing this approved patch on Andrew's behalf.  The cgen parts
 > were approved by FChE off-list.
 > 
 > > bfd/ChangeLog
 > > 	* elf32-xstormy16.c (xstormy16_elf_howto): Add R_XSTORMY16_LO16
 > > 	and R_XSTORMY16_HI16) howto entries.
 > > 	(xstormy16_reloc_map): Map R_XSTORMY16_{LO,HI}16 to BFD_RELOC_{LO,HI}16.
 > > 	(xstormy16_info_to_howto_rela): Use R_XSTORMY16_GNU_VTINHERIT to 
 > > 	determine the start of the second reloc table.
 > > 
 > > cgen/ChangeLog
 > > 	* cpu/xstormy16.cpu (imm16): Call handler immediate16.
 > > 	* cpu/xstormy16.opc (parse_small_immediate): Return on '@'.
 > > 	(parse_immediate16): Handle immediate16 values, which now include
 > > 	@hi(label) and @lo(label)
 > > 
 > > gas/ChangeLog
 > > 	* config/tc-xstormy16.c (md_cgen_lookup_reloc): If a relocation 
 > > 	has already been set up, use it.
 > > 
 > > include/ChangeLog
 > > 	* elf/xstormy16.h (START_RELOC_NUMBERS) Add relocation numbers
 > > 	for R_XSTORMY16_LO16 and R_XSTORMY16_HI16.
 > > 
 > > opcodes/ChangeLog
 > > 	* opcodes/xstormy16-asm.c: Regenerate.

Having to get cgen approval for cpu-specific changes sucks.
People should be able to police their own ports.
gcc port maintainers don't have to get approval for changes to their
ports.  I don't understand why this would be any different.

Is there a reason for this (anal-retentive) procedure?
[I'm not suggesting you or anyone else is actually imposing this of course.
Maybe people just think that's the way things are.]

But, if approval is required, methinks binutils is a better place to
provide approval for .opc changes (e.g. complaints about warnings :-).

Re: New Sanyo Stormy16 relocations

[DJ Delorie]

> Having to get cgen approval for cpu-specific changes sucks.
> People should be able to police their own ports.
> gcc port maintainers don't have to get approval for changes to their
> ports.  I don't understand why this would be any different.

Because cgen feeds binutils, gdb, and sid.  Which one of those has the
port maintainers responsible for cgen?  What happens if a binutils
maintainer changes cgen, and unknowingly breaks sid or gdb?

> But, if approval is required, methinks binutils is a better place to
> provide approval for .opc changes (e.g. complaints about warnings :-).

Better than sid?  Better than gdb?  OTOH we've talked about moving the
port-specific files out of cgen and into their own toplevel directory,
which would remove this issue anyway.

But, let me make the formal request anyway.  gdb and sid cc'd.

Cgen folks (and others)...  would it be acceptable to change the cgen
approval rules to allow people who could otherwise approve
port-specific patches in binutils, gdb, or sid, to be allowed to
approve port-specific changes in cgen as well?

Re: New Sanyo Stormy16 relocations

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

Hi -

On Tue, Dec 17, 2002 at 02:47:03PM -0500, DJ Delorie wrote:
> > Having to get cgen approval for cpu-specific changes sucks.
> > [...]
> 
> Because cgen feeds binutils, gdb, and sid.  Which one of those has the
> port maintainers responsible for cgen?  

Assuming you're referring to cgen model files as opposed to cgen scheme
sources, such port maintainers can work this out amongst themselves.
I see no need for formal process to handle this (hypothetical?) problem.


> What happens if a binutils
> maintainer changes cgen, and unknowingly breaks sid or gdb?

Then as soon as the breakage is identified, the person causing the
breakage will have to negotiate to assure some sort of correction.
No big deal.


> [...]
> But, let me make the formal request anyway.  gdb and sid cc'd.
> 
> Cgen folks (and others)...  would it be acceptable to change the cgen
> approval rules to allow people who could otherwise approve
> port-specific patches in binutils, gdb, or sid, to be allowed to
> approve port-specific changes in cgen as well?

In line with dje's hints, I have no objection, as long as people
stand behind their patch if unforseen negative effects result.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: New Sanyo Stormy16 relocations

[Doug Evans]

DJ Delorie writes:
 > > Having to get cgen approval for cpu-specific changes sucks.
 > > People should be able to police their own ports.
 > > gcc port maintainers don't have to get approval for changes to their
 > > ports.  I don't understand why this would be any different.
 > 
 > Because cgen feeds binutils, gdb, and sid.  Which one of those has the
 > port maintainers responsible for cgen?  What happens if a binutils
 > maintainer changes cgen, and unknowingly breaks sid or gdb?

[Just to be clear, the context of my remarks is changes to .cpu/.opc files.
Nothing else.]

A port maintainer is a port maintainer.

If redhat is the port maintainer for xstormy16 and checks in something to
xstormy16.cpu because they need to change binutils and later find out
they've broken gdb(sim) it's a problem of their own doing.  They can undo it.

Similarily for any port maintainer.

 > > But, if approval is required, methinks binutils is a better place to
 > > provide approval for .opc changes (e.g. complaints about warnings :-).
 > 
 > Better than sid?  Better than gdb?

I don't understand.  The context here is .opc. files.
Changes to .opc files don't affect sid or gdb.  Only binutils.

 > OTOH we've talked about moving the
 > port-specific files out of cgen and into their own toplevel directory,
 > which would remove this issue anyway.
 > 
 > But, let me make the formal request anyway.  gdb and sid cc'd.
 > 
 > Cgen folks (and others)...  would it be acceptable to change the cgen
 > approval rules to allow people who could otherwise approve
 > port-specific patches in binutils, gdb, or sid, to be allowed to
 > approve port-specific changes in cgen as well?

I'm not sure I would word it that way.  Maybe it's ok, I dunno.
uber-hackers in binutils/gdb may be able to make port specific
changes as they deem necessary (are they?).  I'm not sure this should extend
to .cpu files.  But I certainly have no problem with authorized
port maintainers of binutils/gdb making changes to cgen port-specific
files (provided of course they're willing to work through any problems
that may arise).

Given the above seemingly misunderstandings, just so we're clear,
"port-specific changes" means changes to files in src/cgen/cpu
[or whereever they move to].

Re: New Sanyo Stormy16 relocations

[Doug Evans]

Doug Evans writes:
 >  > > But, if approval is required, methinks binutils is a better place to
 >  > > provide approval for .opc changes (e.g. complaints about warnings :-).
 >  > 
 >  > Better than sid?  Better than gdb?
 > 
 > I don't understand.  The context here is .opc. files.
 > Changes to .opc files don't affect sid or gdb.  Only binutils.

[flipping the pedantic bit]
Ok, gdb uses the disassembler.
Still, if src/opcodes is ok for binutils, I don't think
it's a problem for gdb or sid.
And if it is, the problem can be dealt with as it arises.

Re: New Sanyo Stormy16 relocations

[Andrew Cagney]

>> Having to get cgen approval for cpu-specific changes sucks.
>> People should be able to police their own ports.
>> gcc port maintainers don't have to get approval for changes to their
>> ports.  I don't understand why this would be any different.
> 
> 
> Because cgen feeds binutils, gdb, and sid.  Which one of those has the
> port maintainers responsible for cgen?  What happens if a binutils
> maintainer changes cgen, and unknowingly breaks sid or gdb?
> 
> 
>> But, if approval is required, methinks binutils is a better place to
>> provide approval for .opc changes (e.g. complaints about warnings :-).
> 
> 
> Better than sid?  Better than gdb?  OTOH we've talked about moving the
> port-specific files out of cgen and into their own toplevel directory,
> which would remove this issue anyway.
> 
> But, let me make the formal request anyway.  gdb and sid cc'd.
> 
> Cgen folks (and others)...  would it be acceptable to change the cgen
> approval rules to allow people who could otherwise approve
> port-specific patches in binutils, gdb, or sid, to be allowed to
> approve port-specific changes in cgen as well?

This would only all make sense if the .opc et.al. files were all (C) 
FSF.  Which is back to my things-to-do-today list of fill out the 
src/cpu directory a little.

Andrew

Re: New Sanyo Stormy16 relocations

[Frank Ch. Eigler]

cagney wrote:

> [...]
> > Cgen folks (and others)...  would it be acceptable to change the cgen
> > approval rules to allow people who could otherwise approve
> > port-specific patches in binutils, gdb, or sid, to be allowed to
> > approve port-specific changes in cgen as well?
> 
> This would only all make sense if the .opc et.al. files were all (C)
> FSF.  [...]

Sorry, I don't see how that relates to the issue.  Regardless of whose
(C) is on the files, the current matter is which of several potential
maintainer types should feel free to commit changes.


- FChE

Re: New Sanyo Stormy16 relocations

[Ben Elliston]

>>>>> "Doug" == Doug Evans <dje@transmeta.com> writes:

  Doug> But, if approval is required, methinks binutils is a better
  Doug> place to provide approval for .opc changes (e.g. complaints
  Doug> about warnings :-).

I agree that it's a bit counterproductive to post patches to .cpu/.opc
files to the cgen list, since these are just CGEN input files.  The
cgen list can/should be used for discussing changes to cgen itself.
Since a .cpu/.opc change _can_ affect all of the applications
involved, how about sending such patches to binutils@, sid@, et al
rather then cgen@?

If we can reach an agreement, it would be a good idea to update the
MAINTAINERS file to reflect the outcome.

Ben