* Re: New Sanyo Stormy16 relocations [not found] ` <1039043233.28767.313.camel@p4> @ 2002-12-16 19:53 ` DJ Delorie 2002-12-16 20:30 ` Alan Modra 2002-12-17 11:25 ` Doug Evans 0 siblings, 2 replies; 11+ messages in thread From: DJ Delorie @ 2002-12-16 19:53 UTC (permalink / raw) To: amacleod; +Cc: amodra, binutils, cgen 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: New Sanyo Stormy16 relocations 2002-12-16 19:53 ` New Sanyo Stormy16 relocations DJ Delorie @ 2002-12-16 20:30 ` Alan Modra 2002-12-16 20:48 ` DJ Delorie 2002-12-17 11:25 ` Doug Evans 1 sibling, 1 reply; 11+ messages in thread From: Alan Modra @ 2002-12-16 20:30 UTC (permalink / raw) To: Andrew MacLeod; +Cc: DJ Delorie, binutils, cgen 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: New Sanyo Stormy16 relocations 2002-12-16 20:30 ` Alan Modra @ 2002-12-16 20:48 ` DJ Delorie 0 siblings, 0 replies; 11+ messages in thread From: DJ Delorie @ 2002-12-16 20:48 UTC (permalink / raw) To: amodra; +Cc: amacleod, binutils, cgen > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: New Sanyo Stormy16 relocations 2002-12-16 19:53 ` New Sanyo Stormy16 relocations DJ Delorie 2002-12-16 20:30 ` Alan Modra @ 2002-12-17 11:25 ` Doug Evans 2002-12-17 11:47 ` DJ Delorie 2002-12-17 14:39 ` Ben Elliston 1 sibling, 2 replies; 11+ messages in thread From: Doug Evans @ 2002-12-17 11:25 UTC (permalink / raw) To: DJ Delorie; +Cc: amacleod, amodra, binutils, cgen 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 :-). ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: New Sanyo Stormy16 relocations 2002-12-17 11:25 ` Doug Evans @ 2002-12-17 11:47 ` DJ Delorie 2002-12-17 11:56 ` Frank Ch. Eigler ` (2 more replies) 2002-12-17 14:39 ` Ben Elliston 1 sibling, 3 replies; 11+ messages in thread From: DJ Delorie @ 2002-12-17 11:47 UTC (permalink / raw) To: dje; +Cc: binutils, cgen, sid, gdb > 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: New Sanyo Stormy16 relocations 2002-12-17 11:47 ` DJ Delorie @ 2002-12-17 11:56 ` Frank Ch. Eigler 2002-12-17 12:09 ` Doug Evans 2002-12-18 2:37 ` Andrew Cagney 2 siblings, 0 replies; 11+ messages in thread From: Frank Ch. Eigler @ 2002-12-17 11:56 UTC (permalink / raw) To: DJ Delorie; +Cc: binutils, cgen, sid, gdb [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: New Sanyo Stormy16 relocations 2002-12-17 11:47 ` DJ Delorie 2002-12-17 11:56 ` Frank Ch. Eigler @ 2002-12-17 12:09 ` Doug Evans 2002-12-17 12:14 ` Doug Evans 2002-12-18 2:37 ` Andrew Cagney 2 siblings, 1 reply; 11+ messages in thread From: Doug Evans @ 2002-12-17 12:09 UTC (permalink / raw) To: DJ Delorie; +Cc: binutils, cgen, sid, gdb 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]. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: New Sanyo Stormy16 relocations 2002-12-17 12:09 ` Doug Evans @ 2002-12-17 12:14 ` Doug Evans 0 siblings, 0 replies; 11+ messages in thread From: Doug Evans @ 2002-12-17 12:14 UTC (permalink / raw) To: Doug Evans; +Cc: DJ Delorie, binutils, cgen, sid, gdb 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: New Sanyo Stormy16 relocations 2002-12-17 11:47 ` DJ Delorie 2002-12-17 11:56 ` Frank Ch. Eigler 2002-12-17 12:09 ` Doug Evans @ 2002-12-18 2:37 ` Andrew Cagney 2002-12-18 7:47 ` Frank Ch. Eigler 2 siblings, 1 reply; 11+ messages in thread From: Andrew Cagney @ 2002-12-18 2:37 UTC (permalink / raw) To: DJ Delorie; +Cc: dje, binutils, cgen, sid, gdb >> 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: New Sanyo Stormy16 relocations 2002-12-18 2:37 ` Andrew Cagney @ 2002-12-18 7:47 ` Frank Ch. Eigler 0 siblings, 0 replies; 11+ messages in thread From: Frank Ch. Eigler @ 2002-12-18 7:47 UTC (permalink / raw) To: binutils, cgen, sid, gdb 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: New Sanyo Stormy16 relocations 2002-12-17 11:25 ` Doug Evans 2002-12-17 11:47 ` DJ Delorie @ 2002-12-17 14:39 ` Ben Elliston 1 sibling, 0 replies; 11+ messages in thread From: Ben Elliston @ 2002-12-17 14:39 UTC (permalink / raw) To: Doug Evans; +Cc: DJ Delorie, amacleod, amodra, binutils, cgen >>>>> "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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2002-12-18 15:47 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1039041358.28757.307.camel@p4> [not found] ` <20021204225643.GS27956@bubble.sa.bigpond.net.au> [not found] ` <1039043233.28767.313.camel@p4> 2002-12-16 19:53 ` New Sanyo Stormy16 relocations DJ Delorie 2002-12-16 20:30 ` Alan Modra 2002-12-16 20:48 ` DJ Delorie 2002-12-17 11:25 ` Doug Evans 2002-12-17 11:47 ` DJ Delorie 2002-12-17 11:56 ` Frank Ch. Eigler 2002-12-17 12:09 ` Doug Evans 2002-12-17 12:14 ` Doug Evans 2002-12-18 2:37 ` Andrew Cagney 2002-12-18 7:47 ` Frank Ch. Eigler 2002-12-17 14:39 ` Ben Elliston
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).