at list and it isn't tracked in
the database.
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
rching this bug I saw quite a number of these).
Oh, agreed... I'm thinking about the best solution.
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
On Mon, Jun 23, 2008 at 02:19:36PM -0400, Paul Smith wrote:
> On Sat, 2008-06-21 at 11:59 -0400, Daniel Jacobowitz wrote:
> > The release branch has the generated files in it. This is how
> > binutils releases have traditionally been managed. It's the snapshots
> > bef
, to be sure the correct behavior is preserved.
To the best of my knowledge there is no portable way to do this. If
someone else wants to work on it...
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
On Tue, Apr 29, 2008 at 04:27:05PM +0200, Németh Márton wrote:
> Where can I reach the GNU Translation Project robot?
>
> Is there any documentation about this robot?
It's the first google result for "gnu translation project":
translationproject.org.
--
Daniel
this to the GNU Translation Project robot, it will
automatically be picked up for binutils once it's included.
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
d so forth.
>>
>> Should this be getting set to EM_COLDFIRE, or is the existing behavior
>> correct?
>
> I think that it is a bug. ie the number should be EM_COLDFIRE.
The GNU tools never generate EM_COLDFIRE. I think some non-G
7;s __attribute__((hidden)) or -fvisibility=hidden. This is a
difference between ELF linkage and Windows-style DLL linkage.
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
from binutils. It will be fixed in the next release, or you can get a
snapshot.
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
error, including command lines.
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
hat one didn't have to go to sourceware?
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
s?
Try i686-pc-solaris2.10, using GDB 6.5. But I don't think GDB supports
64-bit binaries on Solaris x86.
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
On Fri, Mar 10, 2006 at 08:40:18PM -0500, George M. Gallant, Jr. wrote:
> Daniel,
>
> I don't understand the context of you question. The patch from Nick
> seems to
> fix my concern.
Right - it was directed at Nick.
--
Daniel Jac
,1212
> keep_it = 0;
>
> if (!keep_it)
> ! unlink (out_file_name);
>
> input_scrub_end ();
>
Is this bit unrelated?
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutil
in current versions. It used to
mean that a file could not be reopened, e.g. had been deleted while the
linker was using it.
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
no restriction in ELF about having multiple
sections with the same name; some non-GNU tools do this a lot.
--
Daniel Jacobowitz
CodeSourcery
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
was the latest on
> ftp://sourceware.org/pub/binutils/snapshots - didn't know there was a
> more recent release.
binutils-060130.tar.bz2 is more recent; the things with 2.x.y version
numbers are prerelease snapshots, and the matching final releases are
available in the releases directory.
-
py to
convert to any other formats you want to generate.
> boot.bin: boot.o test.o
> $(LD) $(LFLAGS) boot.o test.o -o $@
> OUTPUT_FORMAT(elf32-little)
> /*OUTPUT_FORMAT(binary)*/
$(LD) $(LFLAGS) boot.o test.o -o [EMAIL PROTECTED]
$(OBJCOPY) -O binary [EMAIL PROT
you will see relocations
associated with the dwarf sections, at the offsets of the "bad"
DW_AT_high_pc fields.
This is not a bug.
--
Daniel Jacobowitz
CodeSourcery, LLC
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
6 it works fine.
>
> I've tried with the following binutils versions with identical results.
> 2.13.2.1
> 2.15.
> 2.16.1
>
> Immediate operands are limited to 8 bits. Then why does 676 work?
You should take another look at the ARM instruction
ch thing down.
The toplevel configure script propogates unknown --with options to all
subdirectories. Have you tried using --with-lib-path?
--
Daniel Jacobowitz
CodeSourcery, LLC
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
ly file with GCC).
Silly question, perhaps, but why not have gas generate R_SPARC_UA32?
--
Daniel Jacobowitz
CodeSourcery, LLC
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
de of the file in which they
are defined, so converting all the symbols to local is definitely not
what you want. Maybe converting them to hidden.
--
Daniel Jacobowitz
CodeSourcery, LLC
___
bug-binutils mailing list
bug-binutils@gnu.org
http://list
t make
> debugging easy.
>
> Can anyone suggest why it is falling over.
It is unlikely that anyone can help you with binutils 2.14 now; could
you try a current version, i.e. 2.16.1?
--
Daniel Jacobowitz
CodeSourcery, LLC
___
bug-binutils maili
24 matches
Mail list logo
