kunal mhaske writes:
> Because the github leak the your engineers id and password
You seem to be confusing binut...@sourceware.org with a Red Hat mailing
list.
Ian
> On Thu 5 Dec, 2019, 9:41 PM Ian Lance Taylor, wrote:
>
>> kunal mhaske writes:
>>
>> > Any
kunal mhaske writes:
> Any update on this?
I don't understand why you are reporting this to bug-binutils@gnu.org.
Ian
"Dey, Shantanu" writes:
> We are not able to download the following:
>
> git clone git://sourceware.org/git/binutils-gdb.git
>
> Please let us know if there is any issue related to the server.
It's working for me.
Does `git clone git:...` work for you using other sites?
Ian
_
Parul Chahar writes:
> I found that a new option "-mfence-as-lock-add" is added in binutils 2.27.
> It generate lock instruction when "-mfence-as-lock-add=yes". Otherwise,
> mfence, lfence, sfence is generated.
>
> Please let me know why this option is required. Why lock instruction is
> needed.
"Fendt, Oliver" writes:
> I think there is a potential licensing problem in the file
> binutils-2.29/gas/config/tc-alpha.c
>
> The license information in the beginning of the files says that this
> file is licensed under GPL-3.0+ ; below this information the CMU
> License is listed. This suggests
pbo writes:
> Confidentiality Notice: The information contained in this e-mail and
> any accompanying attachment(s) is intended only for the use of the
> intended recipient and may be confidential and/or privileged of
> Neusoft Corporation, its subsidiaries and/or its affiliates. If any
> reader
Timothee Cour writes:
> I'm trying to get gold on osx;
> i tried homebrew binutils but it seems to install everything except gold
> I tried configure make from git head but it fails ( Bug 16644)
The gold linker doesn't work on OS X or Windows. It only supports
systems that use ELF.
Ian
__
Bryan Ta writes:
> I encountered the following bugs about global symbol demangling in c++filt
> versions 2.23 and 2.22. Could you please tell me how to fix it?
>
>> c++filt _GLOBAL__sub_I__ZN4AMOS12ContigEdge_t5NCODEE
> _GLOBAL__sub_I__ZN4AMOS12ContigEdge_t5NCODEE
I'm not quite sure what this me
"Lavrentiev, Anton (NIH/NLM/NCBI) [C]" writes:
> There used to be something like a snapshot sequence number (52, 90) like in
> these:
>
> binutils-2.22.52.tar.bz2 21249 KB7/27/2012 12:00:00 AM
> binutils-2.22.90.tar.bz2 20362 KB7/27/2012 12:00:00 AM
>
> but
Apurva Shirish Patil writes:
> While building glibc , one of the pre-requisits is to configure
> and build binutils. While running make after doing ./configure we are
> getting the following errors :
>
> Aborted
> make[3]: *** [libbfd.la] Error 134
> make[3]: Leav
"Vladimir 'φ-coder/phcoder' Serbinenko" writes:
> On 10.03.2012 19:19, Ian Lance Taylor wrote:
>
>> "Vladimir 'φ-coder/phcoder' Serbinenko" writes:
>>
>>> Namely the minimal testcase is:
>>> gcc -o 1.img -ffreestand
"Vladimir 'φ-coder/phcoder' Serbinenko" writes:
> Namely the minimal testcase is:
> gcc -o 1.img -ffreestanding -Wl,-Ttext,0x8200 1.S -nostdlib -m32
> The resulting file has .text at 9200 and not 8200
> 1.S:
> .text
>
> .globl _start
> _start:
Thanks for the report. For gold the -Ttext option s
Roy Batty writes:
> i don't know if your project even has an interest in being compiled with
> anything other than GCC @ this point in time, but here is an error I found
> when trying to make binutils with clang. note that this was performed on a
> fairly standard fedora 16 x86_64-bit install
"Sebastian Klaar" writes:
> I am using gold v1.11 (binutils v2.2) for cross-linking a program for my
> powerpc architecture.
> When I execute this binary I am getting an "Illegal instruction".
> Readelf delivers a correct fileheader (Machine: PowerPC).
>
> Linking with the standard GNU ld create
Josh Ventura writes:
> I filed a bug on the MinGW SourceForge page, and was sent here, or to
> the vicinity of here. Problem is, windres.exe is generating invalid RC
> output.
Probably the best next step would be to file a bug report against the
GNU binutils at http://sourceware.org/bugzilla/ .
Arkadiusz Miskiewicz writes:
> Linux x86_64, 64 bit userspace
>
> binutils 2.21.53.0.2
>
> bfd works fine
> $ ld.bfd -shared -o ulogd_BASE.so ulogd_BASE_sh.o -lc
>
> but gold fails
> $ ld.gold -shared -o ulogd_BASE.so ulogd_BASE_sh.o -lc
> ld.gold: warning: skipping incompatible /usr/lib/libc.so
S Akhtar writes:
> 9. A description of error encountered:
>
> *Unhex: unknown Intel-hex record type: 0x04*
>
> *Unhex: line ‘:02040010EA’::*
>
> *From file ‘hello.hex’; Unrecognized record type*
> A snapshot of the received error is attached for reference.
> *Note: Pleas
simply
> ignores that fact).
>
> IMO gold should match ld.bfd behaviour and simply ignore not a directories.
Makes sense. Fixed like so. Committed to mainline.
Ian
2011-07-02 Ian Lance Taylor
* dirsearch.cc (Dir_cache::read_files): Ignore ENOTDIR errors.
Index: dirsearch.cc
farshad ghassemi toosi writes:
> I faced a very important problem about updating binutils, I wanted to use Qt
> and opengl, I always got error so I search for that and I was advised to
> update my binutils to the version of 2.19.16 or higher of course but I have
> no idea what is Binutils, so I d
"Witold Baryluk" writes:
> Hmm, maybe this Bug have something with common with my gold report?
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620176
Unlikely. However, I just tried to recreate your bug with current
mainline, and failed. It may have been fixed by some other change.
Ian
__
both
mainline and the 2.21 branch.
Ian
2011-05-29 Ian Lance Taylor
* binary.cc (Binary_to_elf::sized_convert): Don't crash if the
binary input file is empty.
Index: binary.cc
===
RCS file: /cvs/src/src/go
-e _start libstart.a
> ./gold/ld-new: warning: cannot find entry symbol '_start'
>
> The results are the same, plus the extra warning.
>
> BFD ld does not have this bug.
> I tested with today's trunk builds of gold and BFD ld.
Thanks. Fixed like so. Commit
Sandro Santilli writes:
> This is :
> binutils-gold 2.20.1-3ubuntu5
The Ubuntu distributors have decided to ship a version of gold which
does not work with the version of libc that they ship. You need to use
the gold from the binutils 2.21 release instead.
See https://bugs.launchpad.net/ubun
Peter Lawrence writes:
> the question I have today is what is the point of all these
> definitions being passed in as arguments to "make", shouldn't
> this have been fixed by "configure", the Makefile is generated by
> "configure", so all these definitions should have
> been finalized at that poi
ali hagigat writes:
> Thank you to reply to my message. Ian, I am using Linux, Fedora 12.
> I typed 'as' as you wrote:
> root> as
> Then I wrote the name of my input file:
> root> asm1.s
> Then i pressed and then and nothing happned!
> For the second time I pressed and now I have the followin
ali hagigat writes:
> My question is about as, GNU assembler, Version 2.14 and I have copied
> the related extract from the manual:
> -
> 1.5 Input Files
> If you give 'as' no file names it attempts to read one input file from
> the as standard input,
> which
Bin Zeng writes:
> There is a compilation error when I tried to build binutils.
> I checked out the fresh copy of binutils from the repository:
>
> cvs -z 9 -d :pserver:anon...@sourceware.org:/cvs/src co binutils
>
> I configure binutils to with --enable-gold --enable-plugins to enable
> gold
Chris Jones writes:
> On 8/2/2010 9:10 AM, Ian Lance Taylor wrote:
>> Chris Jones writes:
>>> I'm trying to get gccgo to go, using the latest sources from binutils
>>> for gold. I did a quick google search, and this doesn't appear to be a
>>> kn
Chris Jones writes:
> I'm trying to get gccgo to go, using the latest sources from binutils
> for gold. I did a quick google search, and this doesn't appear to be a
> known bug. Any help would be greatly appreciated.
What version of g++ are you using to build gold?
Note that while it is useful
> the 32 does not work on 64bit platform (ie. amd64), I believe
> it should be either 32 or 64. When I manually enter 64 there
> on amd64 gold works for me just fine.
Thanks for the report. I think it was just dumb coding on my part. I
committed this patch to fix it.
Ian
Giuseppe Scrivano writes:
> I noticed that ld relocates symbols assigning them always the same
> values in a deterministic way. I am quite sure this is the desired
> behaviour but wouldn't be better to add a bit of randomness?
> Buffer overflow exploits can take advantage to know in advance the
"Arshid, Chetan (IE10)" writes:
> Thanks Ian for the explanation. Can you tell me what kind of data is
> put in .rela.XXX section?
Relocation information. It is displayed by readelf -r or objdump -r.
Ian
> -Original Message-
> From: Ian Lance Taylor [mailto:
"Arshid, Chetan (IE10)" writes:
> I tried to rename the section (of .o file) .data to .persistent.data
> using objcopy utility. It did that, but also renamed the section
> .rela.data to .rela.persistent. I think this is a bug. If not, how do
> I keep the .rela.data section name unchanged?
It
b...@gmx.net writes:
>> The difference in the output appears to be in the strings. This
>> suggests that your compilers are behaving differently than I expect with
>> respect to references to entries in string merge sections. Can you send
>> me just the file TestClass.o? That might be enough fo
tuebened...@yahoo.de writes:
> Not being a linking expert, I assume the object code of fortran
> subroutines is compatible to objects derived from C code. Am I wrong?
Yes, the object code should be compatible.
> ===
> And now for the details: You will fin
Roland Baumann writes:
> this patch indeed fixes my problem. Thanks a lot.
You're welcome. Thanks for reporting the bug.
> Actually, I am wondering whether it makes sense to use "-s" and
> "-shared" together. What information stays in the shared object that I
> am still able to link it?
An EL
k a closer look at the code, and I found a possible problem if
there are local symbols which have to go into the dynamic symbol
table. I committed this patch, which may fix your problem.
Ian
2009-01-15 Ian Lance Taylor
* object.cc (Sized_relobj::wri
Roland Baumann writes:
> I have a problem with gcc 4.1.2 and the gold linker (from binutils
> 2.19). We build shared objects with options "-s" and "-shared"
> together. This leads to assertions in the gold linker. In most cases I
> see
>
> .../gold/real-ld: internal error in get_output_view, at
>
Sharath Manjunatha <[EMAIL PROTECTED]> writes:
> I am using '--debugging' option for the objdump. Is that you are asking?
Yes, --debugging is the same as -g. Neither option supports DWARF.
> And I am using the object compiled with 345 compiler.
I don't know what that compiler is.
Ian
Sharath Manjunatha <[EMAIL PROTECTED]> writes:
> Can anybody tell me, why the below message comes while using "objdump"
> on an object
>
> 1.o: no recognized debugging informatio
>
> 1.o is the object generated by gcc -c -g 1.c -o 1.o
Are you using objdump -g? Nobody ever added support for DW
Paul Koning <[EMAIL PROTECTED]> writes:
> Does anyone have the power to blacklist all traffic from
> *.phenblogs.cc ?
They are blocked.
Ian
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Jan Blunck <[EMAIL PROTECTED]> writes:
> Although the linker script looks ok, the resulting binary isn't executable on
> x86_64. Without defining the program headers in the linker script the
> executable is working fine.
What happens if you use -z max-page-size=0x10 ?
I have tested this on x
Seweryn Habdank-Wojewódzki <[EMAIL PROTECTED]> writes:
> There is a memory leak in ld.so.
>
> A piece of valgrind log file is:
>
> ==9293== at 0x402073E: calloc (in
> /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
> ==9293== by 0x40105C8: allocate_dtv (in /lib/ld-2.4.so)
> ==9293==
[EMAIL PROTECTED] (Joerg Schilling) writes:
> Ian Lance Taylor wrote:
>
> > > group meeting in 1987.
> >
> > ELF was used in SVR4 long before Sun adopted it when they moved from
> > SunOS to Solaris. That said, the version of ELF used in SVR4 was
> &
[EMAIL PROTECTED] (Joerg Schilling) writes:
[EMAIL PROTECTED] (Joerg Schilling) writes:
> Eric Botcazou <[EMAIL PROTECTED]> wrote:
>
> > > Well, Sun did invent ELF, so an extension to ELF made by Sun seems to be
> > > an
> > > official extension that should be supported by all tools.
> >
> > Yo
Amit Gud <[EMAIL PROTECTED]> writes:
> I'm compiling the GNU/Linux kernel as a shared library and I've found
> that relocation entries are created even for absolute symbols. Is
> there any work-around for this, or is it a known bug?
That is correct behaviour if the symbol is globally visible. In
doctor electron <[EMAIL PROTECTED]> writes:
> >You have not described any benefit beyond abstract appeals to what you
> >think object files should look like. That doesn't count. Give us a
> >measurable benefit and we'll consider it.
>
> I did: the vast amount of .obj files containing useful
> p
doctor electron <[EMAIL PROTECTED]> writes:
> 2. As one who finds much in Linux to be very praiseworthy, I
> worry a bit about what seems to be such allegiance to a
> 20-year-old ABI doc which may be inconsistent with making
> quality improvements in the future. [No hardware maker would do
> such
Airr <[EMAIL PROTECTED]> writes:
> As of late yesterday evening, we've been able to get this to work by
> linking the .obj (PE/COFF) files with ld emitting a PE executable, and
> then using objcopy to convert to the final ELF executable.
Yes, that is the usual technique. Of course it only works
doctor electron <[EMAIL PROTECTED]> writes:
> As you might see in Ian's thoughtful reply, I don't think he
> gets the point (maybe my failure to communicate well):
I completely understood what you said.
> ld can get the -4 on its own, rather than read it from "typical"
> input files and thereby
doctor electron <[EMAIL PROTECTED]> writes:
> >> As author of the HotBasic compiler for Windows, in porting same
> >> to Linux, I find that ld does not properly link relative
> >> relocations (R_386_PC32) in correct elf32-i386 .o files.
> >
> >GNU ld is correct according to the ELF ABI Processor S
doctor electron <[EMAIL PROTECTED]> writes:
> As author of the HotBasic compiler for Windows, in porting same
> to Linux, I find that ld does not properly link relative
> relocations (R_386_PC32) in correct elf32-i386 .o files.
GNU ld is correct according to the ELF ABI Processor Supplement for
i
Dennis Heuer <[EMAIL PROTECTED]> writes:
> Today I installed a new i386 linux system from source with linux 2.6.16,
> gcc 4.1.0, glibc 2.4, and binutils 2.16. The problem I have is that ld
> refuses to detect libraries at other locations than /lib and /usr/lib
> though ld.so.conf and (LD_)LIBRARY_
Doug Evans <[EMAIL PROTECTED]> writes:
> Who owns libiberty? Do I file a bugzilla for binutils or gcc or ?
gcc owns libiberty, so: http://gcc.gnu.org/bugzilla/
> vasprintf doesn't watch for long longs so the va_arg() calls
> can get out of sync with what's passed.
Yeah, vasprintf probably need
Lilia Ghachem <[EMAIL PROTECTED]> writes:
> I have a question about the number of histogram records in the profile
> data file: gmon.out file : Can we have more than ONE histogram record?
> in all the tests I made, I found just 1 ...
> So If it's not the case, where these histogram records are sto
Marshall Ward <[EMAIL PROTECTED]> writes:
> The build is successful and I can use the linker, arm-thumb-elf-ld to
> produce ARM opcode. But when I try to link using the interworking tag,
>
> arm-thumb-elf-ld --mthumb-interwork (+ other stuff)
>
> I get the following error message:
>
> arm-t
Nick Clifton <[EMAIL PROTECTED]> writes:
> > The ia64 assembler is choking on `.file ""' with the error message
> > "Zero-length symbol is illegal". According to the GAS manual this
> > should be allowed. The problem is that gcc 3.4 and later now uses
> > `.file ""' instead of `.file ""' when in
PatilSubhash Jayadeep <[EMAIL PROTECTED]> writes:
> Please let me know where can I report GNU Assembler bugs.
http://sourceware.org/bugzilla/
Ian
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> On Tuesday 05 Apr 2005 1:17 am, Ian Lance Taylor wrote:
> > Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > > gcc -I. -c main.c test1.c test2.c
> > > gcc -shared -o libtest1.so test1.o
> > > gcc
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> gcc -I. -c main.c test1.c test2.c
> gcc -shared -o libtest1.so test1.o
> gcc -shared -o libtest2.so test2.o
> gcc -o test -L. -ltest1 main.o
>
> $ ./compile.sh
> ./libtest1.so: undefined reference to `func4'
> collect2: ld returned 1 exit status
"David Du" <[EMAIL PROTECTED]> writes:
> Hi, anybody can answer this question: objdump not working for IBM AIX xcoff
> object file?
Why don't you open a PR at http://sourceware.org/bugzilla/ so that we
don't lose track of this? Thanks.
Ian
___
bug-b
Clytie Siddall <[EMAIL PROTECTED]> writes:
> > IC:%s [%s] has no terminals or sub-classes\n
>
> "terminals" in this case, I am assuming, don't mean VDU installations
> or command-line windows. Would I be correct in translating this to
> mean "terminal variables"? I am unsure. Please dispel a litt
"David Du" <[EMAIL PROTECTED]> writes:
> Hi, Ian, I tried both powerpc-aix and powerpc-elf, when I tested objdump -i,
> they gave me error saying "objdump: can't set BFD default target to
> powerpc-aix: Invalid bfd target" and "objdump: can't set BFD default target
> to powerpc-unknown-elf: Invali
"David Du" <[EMAIL PROTECTED]> writes:
> Hi, Ian, thanks again for your help, I tried to configure
> with --target=rs6000-ibm-aix, and built the binutils, when I tested the
> objdump.exe file with objdump -i, it gave me error: "objdump: can't set BFD
> default target to 'rs6000-ibm-aix': Invalid b
"David Du" <[EMAIL PROTECTED]> writes:
> Hi, Ian, I got what you mean with cygwin, I just built the binutils with the
> help of cygwin, but unfortunately the objdump.exe command donot support
> xcoff format when I run objdump -i, it will list all the supported format, I
> checked the objdump.c sou
"David Du" <[EMAIL PROTECTED]> writes:
> Hi, Ian, thanks for your response again, I checked the binutils/README, it
> talks about how to build for unix-like system, not for windows XP
> environment, for example, it asks to do ./configure command, which in the
> binutils directory is not a DOS or w
"David Du" <[EMAIL PROTECTED]> writes:
> Hi, Ian, thanks for your response, I already downloaded both cygwin and
> binutils, I used objdump of cygwin to dump out ELF format object files for
> my current project under windows XP, now my project needs to support XCOFF
> object file dumping in XP env
"David Du" <[EMAIL PROTECTED]> writes:
> Hi, I need to run objdump under windows XP to dump out XCOFF format object
> files
> created from IBM AIX environment, is that possible? I went to gnu.org site,
> and do not see where I can download the gnu package containing the objdump
> command, anybody
Nilmoni Deb <[EMAIL PROTECTED]> writes:
> > 1) It's traditional Unix behaviour, so changing it will break some
> >programs.
>
> Any example ?
I don't have any specific examples, no.
> > 2) It is more efficient, as the linker can just walk through an
> >archive's symbol table, include al
Nilmoni Deb <[EMAIL PROTECTED]> writes:
> > This is correct and documented behaviour. All Unix linkers behave
> > this way.
>
> In other words, its a feature, not a bug. It seems that the ICC (intel
> cc) on linux does not have this feature.
Really? I haven't tried it myself.
> Just wondering
Nilmoni Deb <[EMAIL PROTECTED]> writes:
> Lets say I am running the following command
>
> gcc z.o -lX -lY -o z
>
> and libX.a depends on a function that is defined in libY.a then the order
> of linking appears to be important. While the previous command works, the
> next one (with order re
"Lyngmo Ted" <[EMAIL PROTECTED]> writes:
> I just downloaded
> http://ftp.gnu.org/gnu/binutils/binutils-2.15.tar.gz
> and compiled it.
>
> When I then did "make install", it couldn't find "./install-sh" in any of the
> subdirectories.
> I hardlinked the top level "install-sh" in every subdirecto
72 matches
Mail list logo
