| To: | Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL> |
|---|---|
| Subject: | Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5 |
| From: | "Maciej W. Rozycki" <macro@linux-mips.org> |
| Date: | Tue, 24 May 2005 12:40:28 +0100 (BST) |
| Cc: | Richard Sandiford <rsandifo@redhat.com>, linux-mips@linux-mips.org |
| In-reply-to: | <Pine.GSO.4.10.10505241242020.25134-100000@helios.et.put.poznan.pl> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <Pine.GSO.4.10.10505241242020.25134-100000@helios.et.put.poznan.pl> |
| Sender: | linux-mips-bounce@linux-mips.org |
On Tue, 24 May 2005, Stanislaw Skowronek wrote: > I tried objcopy (it was my first thought), for one reason or another it > didn't work (internal BFD error something). Reportedly ECOFF is belly-up > in current GNU binutils - at least it is what I heard. And the bug report is... Well, where? > My input is elf32-tradbigmips. So I entirely don't care for binutils' > ECOFF anymore, and I consider this a good thing. As I said, objcopy didn't > work at all. Fixing BFD is not my job (it's a monster of Frankensteinian > proportions), I think that it is actually much easier to write my own > converter (well, I did it, and it works - except that funny HI/LO mismatch > I'm going to work around). Well, you are not required to fix BFD, but if you don't even report problems they are going to be left undiscovered forever... Maciej |
| Previous by Date: | Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5, Stanislaw Skowronek |
|---|---|
| Next by Date: | Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5, Ralf Baechle |
| Previous by Thread: | Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5, Stanislaw Skowronek |
| Next by Thread: | Re: Unmatched R_MIPS_HI16/R_MIPS_LO16 on gcc 3.5, Ralf Baechle |
| Indexes: | [Date] [Thread] [Top] [All Lists] |