Re: [avr-gcc-list] 8-bit relocations on AVR
Andrew Zabolotny z...@homelink.ru wrote: While I was waiting for the papers (they told me it was sent with snail mail, so that's a few months to wait), Well, when I signed mine, I think it took me about a month in total to do it. Funny enough, the original reason was the addition of the AVR-COFF file format to binutils, which never really got committed to the tree (because I realized the implementation was still quite faulty, and because eventually AVR Studio caught up, implememnting ELF+DWARF-2 support so the major reason for having AVR-COFF in the first place vanished). Instead, I filed the papers for GDB and GCC by the same time, and could at least get one larger patch into GCC later on. a guy from Red Hat have committed the patch to trunk: Otlichno, bol'shoye spasibo! -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 8-bit relocations on AVR
From Sun, 21 Feb 2010 06:48:57 -0700 Weddington, Eric eric.wedding...@atmel.com wrote: Thanks for providing this. Do you have a copyright assignment on file with the FSF? That way we can commit your patch into binutils. No :-( What do I do? -- Andrew signature.asc Description: PGP signature ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 8-bit relocations on AVR
Andrew Zabolotny z...@homelink.ru wrote: Thanks for providing this. Do you have a copyright assignment on file with the FSF? That way we can commit your patch into binutils. No :-( What do I do? I think your contribution could still qualify as a medium to small change (given the number of lines of code changed, in comparison with the complexity of the entire binutils package), so you could get away with just a personal disclaimer: http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html There, you can also find the references for the copyright assignment procedure, which might be useful to have anyway in case you intend to further contribute to FSF-maintained software (binutils, GCC, GDB). Note that you need to sign a separate assignment for each of these. (The article referenced is meant to instruct FSF package maintainers, so it's not directly targetted to contributors.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] 8-bit relocations on AVR
-Original Message- From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of Joerg Wunsch Sent: Tuesday, February 23, 2010 12:49 AM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] 8-bit relocations on AVR Andrew Zabolotny z...@homelink.ru wrote: Thanks for providing this. Do you have a copyright assignment on file with the FSF? That way we can commit your patch into binutils. No :-( What do I do? I think your contribution could still qualify as a medium to small change (given the number of lines of code changed, in comparison with the complexity of the entire binutils package), so you could get away with just a personal disclaimer: http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html There, you can also find the references for the copyright assignment procedure, which might be useful to have anyway in case you intend to further contribute to FSF-maintained software (binutils, GCC, GDB). Note that you need to sign a separate assignment for each of these. (The article referenced is meant to instruct FSF package maintainers, so it's not directly targetted to contributors.) Note that FSF's standard for a small change is 10 lines or less that are changed. Or typically something that is obvious. Andrew's patch seems to be a bit more than 10 lines, and is not necessarily an obvious change. However, it is not that big of a patch either. I think you're right that a personal disclaimer might be best. Eric ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 8-bit relocations on AVR
As Weddington, Eric wrote: Note that FSF's standard for a small change is 10 lines or less that are changed. Or typically something that is obvious. Andrew's patch seems to be a bit more than 10 lines, and is not necessarily an obvious change. However, it is not that big of a patch either. I think you're right that a personal disclaimer might be best. I also had that number in mind, and wanted to find a reference for it. Note that the article I've been referring to talks about small to medium changes, without mentioning any figure for it. Maybe they realized that demanding the full procedure from virtually everybody except those fixing just a typo costs them valuable contributions. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] 8-bit relocations on AVR
-Original Message- From: Andrew Zabolotny [mailto:z...@homelink.ru] Sent: Friday, February 19, 2010 2:34 AM To: Weddington, Eric Cc: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] 8-bit relocations on AVR From Tue, 16 Feb 2010 20:28:16 -0700 Weddington, Eric eric.wedding...@atmel.com wrote: Could you also fill out a bug report on the binutils project? And please attach a test case showing the issue that you're trying to solve. It helps for completeness to have everything in one place: bug report, test case, patch. Okay, here is it: http://sourceware.org/bugzilla/show_bug.cgi?id=11297 Hi Andrew, Thanks for providing this. Do you have a copyright assignment on file with the FSF? That way we can commit your patch into binutils. Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 8-bit relocations on AVR
From Tue, 16 Feb 2010 20:28:16 -0700 Weddington, Eric eric.wedding...@atmel.com wrote: Could you also fill out a bug report on the binutils project? And please attach a test case showing the issue that you're trying to solve. It helps for completeness to have everything in one place: bug report, test case, patch. Okay, here is it: http://sourceware.org/bugzilla/show_bug.cgi?id=11297 -- Andrew signature.asc Description: PGP signature ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 8-bit relocations on AVR
From Sun, 14 Feb 2010 03:47:52 -0700 Weddington, Eric eric.wedding...@atmel.com wrote: I can try to make a binutils patch, but I'm not even sure whom I need to contact to push the patch upstream. Me. Okay, it turned out to be pretty easy. Attached is a patch that implements the new relocation type R_AVR_8 in ELF. It works either if the relocation is not optimized out (and, thus, written to the ELF file) as well as for the case when no relocation is emited (or, rather, it's applied directly in gas). I tested it on my code and it works. Will be grateful if somebody will take a look at this. -- Andrew signature.asc Description: PGP signature ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 8-bit relocations on AVR
From Tue, 16 Feb 2010 22:28:47 +0300
Andrew Zabolotny z...@homelink.ru wrote:
Attached is a patch
Ooops, it seems I moved the patch to a different directory before I've
sent the message...
Here goes take two.
--
Andrew
diff -ur binutils-2.18.orig/bfd/elf32-avr.c binutils-2.18/bfd/elf32-avr.c
--- binutils-2.18.orig/bfd/elf32-avr.c 2007-08-06 23:59:24.0 +0400
+++ binutils-2.18/bfd/elf32-avr.c 2010-02-16 21:54:40.0 +0300
@@ -501,7 +501,21 @@
FALSE, /* partial_inplace */
0x,/* src_mask */
0x,/* dst_mask */
- FALSE) /* pcrel_offset */
+ FALSE),/* pcrel_offset */
+ /* 8 bit offset */
+ HOWTO (R_AVR_8, /* type */
+ 0, /* rightshift */
+ 0, /* size (0 = byte, 1 = short, 2 = long) */
+ 8, /* bitsize */
+ FALSE, /* pc_relative */
+ 0, /* bitpos */
+ complain_overflow_bitfield,/* complain_on_overflow */
+ bfd_elf_generic_reloc, /* special_function */
+ R_AVR_8, /* name */
+ FALSE, /* partial_inplace */
+ 0x00ff, /* src_mask */
+ 0x00ff, /* dst_mask */
+ FALSE), /* pcrel_offset */
};
/* Map BFD reloc types to AVR ELF reloc types. */
@@ -539,7 +553,8 @@
{ BFD_RELOC_AVR_CALL, R_AVR_CALL },
{ BFD_RELOC_AVR_LDI, R_AVR_LDI },
{ BFD_RELOC_AVR_6,R_AVR_6},
- { BFD_RELOC_AVR_6_ADIW, R_AVR_6_ADIW }
+ { BFD_RELOC_AVR_6_ADIW, R_AVR_6_ADIW },
+ { BFD_RELOC_8,R_AVR_8 }
};
/* Meant to be filled one day with the wrap around address for the
diff -ur binutils-2.18.orig/gas/config/tc-avr.c binutils-2.18/gas/config/tc-avr.c
--- binutils-2.18.orig/gas/config/tc-avr.c 2010-02-16 21:19:16.0 +0300
+++ binutils-2.18/gas/config/tc-avr.c 2010-02-16 21:17:43.0 +0300
@@ -1131,6 +1131,13 @@
bfd_putl16 ((bfd_vma) value, where);
break;
+ case BFD_RELOC_8:
+ if (value 255 || value -128)
+ as_warn_where (fixP-fx_file, fixP-fx_line,
+ _(operand out of range: %ld), value);
+ *where = value;
+ break;
+
case BFD_RELOC_AVR_16_PM:
bfd_putl16 ((bfd_vma) (value 1), where);
break;
@@ -1418,7 +1425,9 @@
{
if (exp_mod_pm == 0)
{
- if (nbytes == 2)
+ if (nbytes == 1)
+ fix_new_exp (frag, where, nbytes, exp, FALSE, BFD_RELOC_8);
+ else if (nbytes == 2)
fix_new_exp (frag, where, nbytes, exp, FALSE, BFD_RELOC_16);
else if (nbytes == 4)
fix_new_exp (frag, where, nbytes, exp, FALSE, BFD_RELOC_32);
diff -ur binutils-2.18.orig/include/elf/avr.h binutils-2.18/include/elf/avr.h
--- binutils-2.18.orig/include/elf/avr.h 2006-05-24 11:36:11.0 +0400
+++ binutils-2.18/include/elf/avr.h 2010-02-16 21:28:28.0 +0300
@@ -65,6 +65,7 @@
RELOC_NUMBER (R_AVR_MS8_LDI_NEG, 23)
RELOC_NUMBER (R_AVR_LO8_LDI_GS, 24)
RELOC_NUMBER (R_AVR_HI8_LDI_GS, 25)
+ RELOC_NUMBER (R_AVR_8, 26)
END_RELOC_NUMBERS (R_AVR_max)
#endif /* _ELF_AVR_H */
signature.asc
Description: PGP signature
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] 8-bit relocations on AVR
-Original Message- From: Andrew Zabolotny [mailto:z...@homelink.ru] Sent: Wednesday, February 17, 2010 2:39 AM To: Weddington, Eric Cc: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] 8-bit relocations on AVR From Tue, 16 Feb 2010 22:28:47 +0300 Andrew Zabolotny z...@homelink.ru wrote: Attached is a patch Ooops, it seems I moved the patch to a different directory before I've sent the message... Here goes take two. Could you also fill out a bug report on the binutils project? And please attach a test case showing the issue that you're trying to solve. It helps for completeness to have everything in one place: bug report, test case, patch. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 8-bit relocations on AVR
From Mon, 15 Feb 2010 08:27:25 +0100 (MET) j...@uriah.heep.sax.de (Joerg Wunsch) wrote: Btw., to prove this is really a deficiency, it might suffice to demonstrate that the very same GNU assembler can handle this situation for other architectures pretty well: Well, I wouldn't call this a bug, it's rather a enhancement or missing feature. In the case with ldi it was solved with a quick'n'dirty hack (I mean lo8/hi8) I'll see if I can afford a patch. And of course, it won't have anything to do with the FORTH kernel I'm doing, it's just a particular application that hit this problem. -- Andrew signature.asc Description: PGP signature ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 8-bit relocations on AVR
From Sun, 14 Feb 2010 11:12:03 +1100 Erik Christiansen dva...@internode.on.net wrote: If you have no objection to each message having global labels, it is not only achievable (via the ldi or ldd relocations), but the need to store the string length is avoided: .section .text ; In the code somewhere, we compute the length when it's needed: ldi r16,(end_msg1 - msg1) ; or, depending on needs: ldd r20,Y+(end_msg1 - msg1) msg1: .ascii somestring end_msg1: Does that come close enough to meeting your needs? Unfortunately, I can't imagine how this would help me. Well, to be concrete, I'm implementing a simple FORTH virtual machine. A FORTH word (it's what we call subroutines in other programming languages) begins with a header, and this header contains the length of the name (in fact, the length is contained in lower 5 bits, upper 3 bits are reserved for various flags) before the name itself. This all works on x86 and x86_64 just fine, problem arised when I've tried to port it to avr. I can try to make a binutils patch, but I'm not even sure whom I need to contact to push the patch upstream. -- Andrew signature.asc Description: PGP signature ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] 8-bit relocations on AVR
-Original Message- From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of Andrew Zabolotny Sent: Sunday, February 14, 2010 3:43 PM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] 8-bit relocations on AVR I can try to make a binutils patch, but I'm not even sure whom I need to contact to push the patch upstream. Me. It depends on if this patch fixes a known bug, or if this is specific to your Forth implementation. If it is for a bug, then a bug report needs to be filled out on the Binutils bug database, along with a test case to show the bug. You can put me into the CC list of the bug report. It also depends on the type of fix and how obvious it is. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 8-bit relocations on AVR
On Sun, Feb 14, 2010 at 03:47:52AM -0700, Weddington, Eric wrote: It depends on if this patch fixes a known bug, or if this is specific to your Forth implementation. AIUI, Andrew's observed failure of avr-as to handle: .byte 2f-1f 1: .ascii somestring 2: is a well known bug, even if not recorded. Giving .byte the same address computing ability as ldi has long had, and Klaus Rudolph gave to ldd back in 2004, is rectification of a long-standing generic defect. Erik -- Due to circumstances beyond our control, we regret to inform you that circumstances are beyond our control. --Paul Benoit ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 8-bit relocations on AVR
Erik Christiansen dva...@internode.on.net wrote: [...] is a well known bug, even if not recorded. It might make Eric's work easier to at least file a bug report for it. Btw., to prove this is really a deficiency, it might suffice to demonstrate that the very same GNU assembler can handle this situation for other architectures pretty well: j...@uriah 1836% cat foo.s ..byte 2f - 1f 1: .ascii Hello, world! 2: j...@uriah 1837% as -o foo.o foo.s j...@uriah 1838% objdump -s foo.o foo.o: file format elf32-i386-freebsd Contents of section .text: 0d48656c 6c6f2c20 776f726c 6421 .Hello, world! j...@uriah 1839% avr-as -o foo.o foo.s foo.s: Assembler messages: foo.s:1: Error: illegal relocation size: 1 -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] 8-bit relocations on AVR
On Sat, Feb 13, 2010 at 08:35:44PM +0300, Andrew Zabolotny wrote: .byte 2f-1f 1:.ascii somestring 2: This has been a source of occasional irritation for more than half a decade now. Klaus Rudolph fixed a couple of cases in a patch, back in 2004, but this one remains. I understand that avr-as could be patched to support 8-bit relocations (I even found where - gas/config/tc-avr.c, function avr_cons_fix_new()). Yes, that file rings bells. So, is there any other way to do what I want? If you have no objection to each message having global labels, it is not only achievable (via the ldi or ldd relocations), but the need to store the string length is avoided: .section .text ; In the code somewhere, we compute the length when it's needed: ldi r16,(end_msg1 - msg1) ; or, depending on needs: ldd r20,Y+(end_msg1 - msg1) msg1: .ascii somestring end_msg1: Does that come close enough to meeting your needs? Erik -- There is nothing new under the sun, but there are lots of old things we don't know yet. -Ambrose Bierce ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
