Re: Bug Report ( sensitive information on Github )

[Ian Lance Taylor]

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 update on this?
>>
>> I don't understand why you are reporting this to bug-binutils@gnu.org.
>>
>> Ian
>>

Re: Bug Report ( sensitive information on Github )

[Ian Lance Taylor]

kunal mhaske  writes:

> Any update on this?

I don't understand why you are reporting this to bug-binutils@gnu.org.

Ian

Re: FW: binutils-gdb.git: connection timed out

[Ian Lance Taylor]

"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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: -mfence-as-lock-add option in binutils 2.27

[Ian Lance Taylor]

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.

It's not needed, but it can be more efficient.  See, for example,

https://shipilev.net/blog/2014/on-the-fence-with-dependencies/#_hardware

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Potential Licensing Problem in binutils-2.29/gas/config/tc-alpha.c

[Ian Lance Taylor]

"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 that the file itself stays under
> GPL-3.0 and CMU.
> The CMU has among others wording that reads:
>
> Carnegie Mellon requests users of this software to return to
>
> ??? Software Distribution Coordinator? or? software.distribut...@cs.cmu.edu
> ??? School of Computer Science
> ??? Carnegie Mellon University
> ??? Pittsburgh PA 15213-3890
> ? any improvements or extensions that they make and grant Carnegie the
> ?? rights to redistribute these changes.? */
>
> so it is requested that all modifications are sent back to the
> CMU. Such a requirement is not formulated in the GPL-3.0 and the
> GPL-3.0 says in section

It's only a request, not a requirement.  I don't see a problem here.

I do kind of wonder what that text is doing on an Alpha source file.  As
far as I know Mach never ran on the Alpha.  Our repository history don't
go back far enough to show where it came from.  I suppose we could ask
Richard Henderson to see if he remembers.

I also wonder how many people would notice if we just dropped Alpha
support.  They stopped selling Alpha machines ten years ago.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Possibly a typo in function prototype

[Ian Lance Taylor]

pbo p...@neusoft.com 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 of this communication is not the intended recipient,
 unauthorized use, forwarding, printing,  storing, disclosure or
 copying is strictly prohibited, and may be unlawful.If you have
 received this communication in error,please immediately notify the
 sender by return e-mail, and delete the original message and all
 copies from your system. Thank
 you. 
 ---

I was going to answer, but I saw this.  Please avoid sending e-mail
messages with this kind of disclaimer to the binutils mailing list.
They are against list policy.  We can not honor the disclaimer, as the
list is publically archived.  If your company does not permit you to
send e-mail without the disclaimer, consider using a free webmail
account instead.  Thanks.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: how to get binutils gold on osx

[Ian Lance Taylor]

Timothee Cour timothee.co...@gmail.com 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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Global symbol demangling issue in c++filt

[Ian Lance Taylor]

Bryan Ta dungtq1...@gmail.com 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 means, but certainly the demangler doesn't
handle it.  g++ seems to generate it to run a set of global
constructors.  Please file a bug report with a test case as described at
http://gcc.gnu.org/bugs/ .  Thanks.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Current binutils snapshots archives missing sequence number?

[Ian Lance Taylor]

Lavrentiev, Anton (NIH/NLM/NCBI) [C] l...@ncbi.nlm.nih.gov 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 seems no longer to be the case for more recent snapshot(s):

 binutils-2.23.0.tar.bz2   20948 KB11/6/2012   9:05:00 AM
 binutils.tar.bz2  22594 KB3/18/2013   5:43:00 AM
 binutils-.tar.bz2 22594 KB3/18/2013   5:43:00 AM


This may have been broken since this change:

2012-07-27  Mike Frysinger  vap...@gentoo.org

* configure.in (AC_INIT): Call with the args bfd and 2.22.52.
(AM_INIT_AUTOMAKE): Remove args.

See the way that VER is set in the top-level src-release script.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Glibc installation

[Ian Lance Taylor]

Apurva Shirish Patil apurva...@gmail.com 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]: Leaving directory
 `/home/student/Desktop/glibc/binutils-2.14/bfd'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory
 `/home/student/Desktop/glibc/binutils-2.14/bfd'
 make[1]: *** [all-recursive-am] Error 2
 make[1]: Leaving directory
 `/home/student/Desktop/glibc/binutils-2.14/bfd'
 make: *** [all-bfd] Error 2

You need to show us more lines of the make output.  That is not enough
to see what has gone wrong.

That said, make sure you did not run out of disk space.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: gold mistreats -Wl,-Ttext,0x8200

[Ian Lance Taylor]

Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com writes:

 On 10.03.2012 19:19, Ian Lance Taylor wrote:

 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com 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 sets the address of
 the text segment, not the .text section.  When I try your test case with
 current gold the text segment does indeed start at 0x8200, as expected.
 

 Hello, I still do need a way to put everything in one chunk without
 holes which starts at a given address. Otherwise GRUB can't be compiled
 with gold.

Are you saying that you can not do this with gold?

Please open a complete bug report at http://sourceware.org/bugzilla ,
with the files needed to recreate the problem.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: gold mistreats -Wl,-Ttext,0x8200

[Ian Lance Taylor]

Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com 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 sets the address of
the text segment, not the .text section.  When I try your test case with
current gold the text segment does indeed start at 0x8200, as expected.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: error compiling binutils-2.22 with clang v2.9

[Ian Lance Taylor]

Roy Batty nexus6royba...@yahoo.com 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 ( using 
 kernel 3.2.9-1.fc16.x86_64 #1 SMP )  ... hope this is of some use to your 
 project.  let me know if you need further information.



 libtool: compile:  clang -DHAVE_CONFIG_H -I. -I. -I. -I./../include 
 -DHAVE_bfd_elf64_x86_64_vec -DHAVE_bfd_elf32_i386_vec 
 -DHAVE_bfd_elf32_x86_64_vec -DHAVE_i386linux_vec -DHAVE_i386pei_vec 
 -DHAVE_x86_64pei_vec -DHAVE_bfd_elf64_l1om_vec -DHAVE_bfd_elf64_k1om_vec 
 -DHAVE_bfd_elf64_little_generic_vec -DHAVE_bfd_elf64_big_generic_vec 
 -DHAVE_bfd_elf32_little_generic_vec -DHAVE_bfd_elf32_big_generic_vec 
 -DBINDIR=\/usr/local/bin\ -W -Wall -Wstrict-prototypes -Wmissing-prototypes 
 -Wshadow -Werror -g -O2 -MT opncls.lo -MD -MP -MF .deps/opncls.Tpo -c 
 opncls.c -o opncls.o
 opncls.c:249:5: error: expression result unused [-Werror,-Wunused-value]
     bfd_set_cacheable (nbfd, TRUE);
     ^~
 In file included from opncls.c:26:
 ./bfd.h:524:67: note: instantiated from:
 #define bfd_set_cacheable(abfd,bool) (((abfd)-cacheable = bool), TRUE)
                                                                   ^
 ./bfd.h:127:14: note: instantiated from:
 #define TRUE 1
              ^
 1 error generated.
 *** Error code 1


There is nothing wrong with this code.  It is working as intended.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: gold-linked binary for ppc results in illegal instruction

[Ian Lance Taylor]

Sebastian Klaar skl...@gmx.net 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 creates a runnable binary, but of course 
 needs a lot longer.

 I compiled gold before for arm. Worked like a charm!

The gold PowerPC support is incomplete.  Sorry.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: ld gold stops looking for lib if it finds incompatible one first

[Ian Lance Taylor]

Arkadiusz Miskiewicz ar...@maven.pl 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 while searching for c
 ld.gold: error: cannot find -lc

Can you send me the ulogd_BASE_sh.o file?

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: ld.gold doesn't like if -L points to not a directory

[Ian Lance Taylor]

Arkadiusz Miskiewicz ar...@maven.pl writes:

 [arekm@ixion-pld ~]$ more ~/test/x.c
 int main() { return 0; }
 [arekm@ixion-pld ~]$ g++ -L/bin/sh ~/test/x.c
 /usr/bin/ld: error: /bin/sh: can not read directory: Not a directory
 collect2: ld returned 1 exit status

 but

 [arekm@ixion-pld ~]$ g++ -L/notexistant ~/test/x.c
 [arekm@ixion-pld ~]$

 (doesn't complain)

 $ ld --version
 GNU gold (Linux/GNU Binutils 2.21.52.0.2.20110610) 1.11
 [...]

 Note that ld.bfd has no trouble with -L pointing to not a directory (it 
 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  i...@google.com

* dirsearch.cc (Dir_cache::read_files): Ignore ENOTDIR errors.


Index: dirsearch.cc
===
RCS file: /cvs/src/src/gold/dirsearch.cc,v
retrieving revision 1.13
diff -u -p -r1.13 dirsearch.cc
--- dirsearch.cc	25 May 2011 06:15:28 -	1.13
+++ dirsearch.cc	3 Jul 2011 04:15:01 -
@@ -66,8 +66,9 @@ Dir_cache::read_files()
   DIR* d = opendir(this-dirname_);
   if (d == NULL)
 {
-  // We ignore directories which do not exist.
-  if (errno != ENOENT)
+  // We ignore directories which do not exist or are actually file
+  // names.
+  if (errno != ENOENT  errno != ENOTDIR)
 	gold::gold_error(_(%s: can not read directory: %s),
 			 this-dirname_, strerror(errno));
   return;
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: ld.gold: internal error in make_view, at fileread.cc:458

[Ian Lance Taylor]

Witold Baryluk bary...@smp.if.uj.edu.pl 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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: ld.gold: internal error in make_view, at fileread.cc:458

[Ian Lance Taylor]

Arkadiusz Miskiewicz ar...@maven.pl writes:

 uClibc does one test and checks exit status. For gold it causes internal 
 error.

 binutils 2.21.51.0.9 on x86_64 linux.

 $ ld.gold --hash-style=gnu -o /dev/null -b binary /dev/null
 ld.gold: internal error in make_view, at fileread.cc:458
 zsh: exit 1 ld.gold --hash-style=gnu -o /dev/null -b binary /dev/null

 $ ld.bfd --hash-style=gnu -o /dev/null -b binary /dev/null
 ld.bfd: warning: cannot find entry symbol _start; not setting start address

Thanks for the bug report.  Fixed with this patch, committed to both
mainline and the 2.21 branch.

Ian


2011-05-29  Ian Lance Taylor  i...@google.com

* 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/gold/binary.cc,v
retrieving revision 1.4
diff -p -u -r1.4 binary.cc
--- binary.cc	7 Feb 2009 01:03:32 -	1.4
+++ binary.cc	29 May 2011 17:08:52 -
@@ -132,7 +132,11 @@ Binary_to_elf::sized_convert(const Task*
 }
 
   section_size_type filesize = convert_to_section_size_type(f.filesize());
-  const unsigned char* fileview = f.get_view(0, 0, filesize, false, false);
+  const unsigned char* fileview;
+  if (filesize == 0)
+fileview = NULL;
+  else
+fileview = f.get_view(0, 0, filesize, false, false);
 
   unsigned int align;
   if (size == 32)
@@ -223,10 +227,13 @@ Binary_to_elf::sized_convert(const Task*
 	   shstrtab.get_strtab_size(),
 	   0, 0, 1, 0, pout);
 
-  memcpy(pout, fileview, filesize);
-  pout += filesize;
-  memset(pout, 0, aligned_filesize - filesize);
-  pout += aligned_filesize - filesize;
+  if (filesize  0)
+{
+  memcpy(pout, fileview, filesize);
+  pout += filesize;
+  memset(pout, 0, aligned_filesize - filesize);
+  pout += aligned_filesize - filesize;
+}
 
   this-write_symbolsize, big_endian(, strtab, 0, 0, pout);
   this-write_symbolsize, big_endian(start_symbol_name, strtab, 0, 1,
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: gold linker issues with PostGIS cunit tests

[Ian Lance Taylor]

Sandro Santilli s...@keybit.net 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/ubuntu/+source/binutils/+bug/673893 .

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: what the...???...

[Ian Lance Taylor]

Peter Lawrence peterl95...@sbcglobal.net 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 point and the Makefile should already be wired
 with the correct definitions, there should not be
 any definitional arguments being passed in to make

Passing the arguments down makes it easy for the user/developer to
override them on the make command line, in a way that works reliably
with various different implementations of make.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: How to use control-D character?

[Ian Lance Taylor]

ali hagigat hagigat...@gmail.com 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 ENTER and then ctl-D and nothing happned!
 For the second time I pressed  ctl-D and now I have the following
 error message:
 {standard input}: Assembler messages:
 {standard input}:1: Error: no such instruction: `asm1.s'

 I think you meant writing some assembly instructions before CTL-D.
 But when I type:
 root as  ENTER
 root mov  $0, %eax  ENTER
 root CAPS LOCK CTL-D
 nothing happens!! but if i press CTL-D for two more times, it will
 exit from as and returns back to my shell prompt!
 So what happened? Did it assemble the line? Why this CTL-D is
 useful, how it is used?

As noted in http://en.wikipedia.org/wiki/End-of-file , ^D is the
standard Unix end-of-file indicator from the terminal.  You don't need
to use the caps lock or the shift key; pressing the control key and the
D key simultaneously is sufficient.

The fact that you have to type ^D more than once seems like a bug in the
GNU assembler.  Please consider reporting it at
http://sourceware.org/bugzilla/ .

And, yes, when you do type it more than once, and the assembler exits,
then it has assembled the line you typed.  You will find the results in
the file a.out.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: How to use control-D character?

[Ian Lance Taylor]

ali hagigat hagigat...@gmail.com 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 is normally your terminal. You may have to type ctl-D to tell as
 there is no more
 program to assemble.
 

 How can i use ctl-D key combination? Will it be typed at the end of
 'as' command line?
 When i type:
 as ctl-D
 'as' will wait for user to enter some lines of instruction!!

 If I use 'as' alone and then enter some assembly lines , how can i
 terminate the input terminal text and make 'as' assemble the lines I
 have written?

http://en.wikipedia.org/wiki/End-of-file

In other words, type

as
your input file
^D

This assumes that you are using Unix or GNU/Linux; you didn't say.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: compilation error

[Ian Lance Taylor]

Bin Zeng ezeng...@gmail.com 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 and plugins.

 ../../src/gold/arm.cc:2135: internal compiler error: in
 make_rtl_for_nonlocal_decl, at cp/decl.c:5067
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See URL:http://bugzilla.redhat.com/bugzilla for instructions.
 Preprocessed source stored into /tmp/cczIynyz.out file, please attach
 this to your bugreport.

This is an internal compiler error from gcc.  It's not a problem with
the GNU binutils.  Please report it as a gcc bug, either at the web site
mentioned in the error message, or following the guidelines at
http://gcc.gnu.org/bugs/ .  Thanks.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: can't build gold on FreeBSD

[Ian Lance Taylor]

Chris Jones ch...@cjones.org 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 to use gold with gccgo on x86/x86_64, there
is currently no advantage to doing so on SPARC.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: can't build gold on FreeBSD

[Ian Lance Taylor]

Chris Jones ch...@cjones.org writes:

  On 8/2/2010 9:10 AM, Ian Lance Taylor wrote:
 Chris Jonesch...@cjones.org  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?

 The stock one that comes with FreeBSD:

 maxwell$ g++ -v
 Using built-in specs.
 Target: i386-undermydesk-freebsd
 Configured with: FreeBSD/i386 system compiler
 Thread model: posix
 gcc version 4.2.1 20070719  [FreeBSD]

Thanks.  I committed a patch which should fix the problem.

Ian

___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: 32bits specific code in do_adjust_elf_header()

[Ian Lance Taylor]

Roman Divacky rdiva...@freebsd.org writes:

 Target_freebsdsize, big_endian::do_adjust_elf_header()

 there is 32specific code that does not work on 64bit platforms

 this:

  gold_assert(len == elfcpp::Elf_sizes32::ehdr_size);

  elfcpp::Ehdr32, false ehdr(view);


 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


2009-07-01  Ian Lance Taylor  i...@airs.com

* freebsd.h (Target_freebsd::do_adjust_elf_header): Use size
instead of 32.


Index: freebsd.h
===
RCS file: /cvs/src/src/gold/freebsd.h,v
retrieving revision 1.1
diff -p -u -r1.1 freebsd.h
--- freebsd.h	24 Mar 2009 00:31:28 -	1.1
+++ freebsd.h	1 Jul 2009 16:20:44 -
@@ -68,15 +68,15 @@ Target_freebsdsize, big_endian::do_adj
 {
   if (this-osabi_ != elfcpp::ELFOSABI_NONE)
 {
-  gold_assert(len == elfcpp::Elf_sizes32::ehdr_size);
+  gold_assert(len == elfcpp::Elf_sizessize::ehdr_size);
 
-  elfcpp::Ehdr32, false ehdr(view);
+  elfcpp::Ehdrsize, false ehdr(view);
   unsigned char e_ident[elfcpp::EI_NIDENT];
   memcpy(e_ident, ehdr.get_e_ident(), elfcpp::EI_NIDENT);
 
   e_ident[elfcpp::EI_OSABI] = this-osabi_;
 
-  elfcpp::Ehdr_write32, false oehdr(view);
+  elfcpp::Ehdr_writesize, false oehdr(view);
   oehdr.put_e_ident(e_ident);
 }
 }
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: nondeterministic symbols relocation

[Ian Lance Taylor]

Giuseppe Scrivano gscriv...@gnu.org 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
 position of a symbol, it will not solve completely the problem but
 surely it will make things harder.

 Does something similar already exist?  Is it a reasonable idea?

Exploits which rely on the position of symbols are based on popular
binaries which have already been linked.  Binaries are not routinely
relinked.  Randomizing the behaviour at relink time would have a
vanishingly small effect on security.

Randomizing addresses at runtime would have slightly more effect.
That is already implemented in the linker and GNU/Linux kernel, via
-pie.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Bug in objcopy?

[Ian Lance Taylor]

Arshid, Chetan (IE10) chetan.ars...@honeywell.com 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:i...@airs.com] 
 Sent: Saturday, May 23, 2009 12:10 PM
 To: Arshid, Chetan (IE10)
 Cc: bug-binutils@gnu.org
 Subject: Re: Bug in objcopy?

 Arshid, Chetan (IE10) chetan.ars...@honeywell.com 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 doesn't sound like a bug.  Normally the .rela.XXX section applies
 to the .XXX section.  If you rename a section, it seems natural to
 rename the corresponding .rela section.

 As far as I know there is no way to keep this from happening.

 Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: gold: problems with mixed C++/Fortran program

[Ian Lance Taylor]

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 find

 1) file list
 2) Makefile
 3/4) C++ test class source and header
 5/6) Fortran test routine source and header
 7) main routine in test.C
 8) version strings of the compilers and linkers used
 9) compile and run log using GNU ld (-- this output is what I expected!)
 10) compile and run log using GNU gold 
  (-- search for Hi guys... strange,isn't it? I think it isn't just a C/F90 
 problem.)

Thanks for the detailed bug report.  Unfortunately, I can't do anything
with it as I don't have the icpc or ifort programs.  Also unfortunately,
in order to get a reproducible test case I would most likely need to
have the libraries, which you are probably not allowed to send me.

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 for me to see the
problem.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: gold: problems with mixed C++/Fortran program

[Ian Lance Taylor]

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 for me to see the
 problem.
 Yes, in the tarball below. See the directories using_*ld

Thanks for sending the object files.  Now I remember.  I've seen this
problem before and reported it to Intel before.  They are generating
object files which do not follow the x86_64 ELF ABI.  The x86_64 ELF ABI
specifies that the relocation computation for R_X86_64_32 is simply S +
A.  The ABI says:

S Represents the value of the symbol whose index resides in the
  relocation entry.

A Represents the addend used to compute the value of the relocatable
  field.

The AMD64 ABI architectures uses only Elf64_Rela relocation entries
with explicit addends.  The r_addend member serves as the relocation
addend.

So this is all clear enough, and gas complies with it.

However, in the object file you sent me, I see this using objdump -dr:

 142:   ba 14 00 00 00  mov$0x14,%edx
143: R_X86_64_32.rodata

and this using readelf -r:

0143  000d000a R_X86_64_32    .rodata + 0

As you can see, the r_addend member for this relocation has the value 0.
There is a 0x14 stored in the instruction itself, but the x86_64 ELF ABI
says that that field should be ignored.

As it happens, the GNU linker does not ignore that field.  It
incorrectly adds the value in the field in the instruction into the
final relocation value.  (This is because the src_mask field in the
howto entry for R_X86_64_32 in bfd/elf64-x86-64.c is 0x when it
should be 0; this bug dates back to the initial creation of the file).
That is why this object file works with the GNU linker.

So the problem that gold faces is whether it should adhere to the
published ABI, or whether it should emulate the GNU linker.  Adhering to
the published ABI does work correctly with output from the GNU tools.
Unfortunately, as you have discovered, the Intel tools generate
incorrect output which does not follow the ABI, and gold does not work
with them.

My preference would be for Intel to fix their tools to conform to the
published ABI.  Then there will be no confusion going forward.  If you
have purchased a copy of the Intel compilers, I encourage you to report
the bug.  I would be happy to provide more details and arguments if
required.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: gold and shared objects with gcc 4.1.2

[Ian Lance Taylor]

Roland Baumann roland.baum...@coware.com 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 ELF shared object has two symbol tables: the dynamic symbol table
and the normal symbol table.  The -s option removes the normal symbol
table.  The dynamic symbol table contains whatever is needed for
dynamic linking.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: gold and shared objects with gcc 4.1.2

[Ian Lance Taylor]

Roland Baumann roland.baum...@coware.com writes:


 I compile this with:

 g++-4.1.2 -c test_shared.cc -o test_shared.o
 g++-4.1.2 -B path_to_gold -shared -s test_shared.o -o test_shared.so

 I'm not able to recreate this problem with either binutils 2.19 or
 with the development version.  Can you post the output of your -shared
 command line with the -v option?  That will show precisely how the
 linker is being invoked.


 Here it comes:

Thanks.  Unfortunately I still can't recreate it.

I took 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  i...@google.com

* object.cc (Sized_relobj::write_local_symbols): Don't write out
local symbols when stripping all symbols.


Index: object.cc
===
RCS file: /cvs/src/src/gold/object.cc,v
retrieving revision 1.79
diff -p -u -r1.79 object.cc
--- object.cc	23 Dec 2008 02:02:20 -	1.79
+++ object.cc	15 Jan 2009 18:01:55 -
@@ -1416,9 +1416,13 @@ Sized_relobjsize, big_endian::write_lo
 Output_symtab_xindex* symtab_xindex,
 Output_symtab_xindex* dynsym_xindex)
 {
-  if (parameters-options().strip_all()
-   this-output_local_dynsym_count_ == 0)
-return;
+  const bool strip_all = parameters-options().strip_all();
+  if (strip_all)
+{
+  if (this-output_local_dynsym_count_ == 0)
+	return;
+  this-output_local_symbol_count_ = 0;
+}
 
   gold_assert(this-symtab_shndx_ != -1U);
   if (this-symtab_shndx_ == 0)
@@ -1487,7 +1491,7 @@ Sized_relobjsize, big_endian::write_lo
 	  st_shndx = out_sections[st_shndx]-out_shndx();
 	  if (st_shndx = elfcpp::SHN_LORESERVE)
 	{
-	  if (lv.needs_output_symtab_entry())
+	  if (lv.needs_output_symtab_entry()  !strip_all)
 		symtab_xindex-add(lv.output_symtab_index(), st_shndx);
 	  if (lv.needs_output_dynsym_entry())
 		dynsym_xindex-add(lv.output_dynsym_index(), st_shndx);
@@ -1496,8 +1500,7 @@ Sized_relobjsize, big_endian::write_lo
 	}
 
   // Write the symbol to the output symbol table.
-  if (!parameters-options().strip_all()
-	   lv.needs_output_symtab_entry())
+  if (!strip_all  lv.needs_output_symtab_entry())
 {
   elfcpp::Sym_writesize, big_endian osym(ov);
 
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: gold and shared objects with gcc 4.1.2

[Ian Lance Taylor]

Roland Baumann roland.baum...@coware.com 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
 ...src/binutils-2.19/gold/output.h:3081
 collect2: ld returned 1 exit status

 But for the very simple example provided below, I see a different assertion:

 .../gold/real-ld: internal error in write_local_symbols, at
 .../src/binutils-2.19/gold/object.cc:1471
 collect2: ld returned 1 exit status

 The example to trigger this error is:

 --
 #include iostream
 void print() {
   std::cout  Hello World!  std::endl;
 }
 --

 I compile this with:

 g++-4.1.2 -c test_shared.cc -o test_shared.o
 g++-4.1.2 -B path_to_gold -shared -s test_shared.o -o test_shared.so

I'm not able to recreate this problem with either binutils 2.19 or
with the development version.  Can you post the output of your -shared
command line with the -v option?  That will show precisely how the
linker is being invoked.

Also, for which target did you configure?

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: FW: objdump says 'no recognized debugging informatio'

[Ian Lance Taylor]

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


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: FW: objdump says 'no recognized debugging informatio'

[Ian Lance Taylor]

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 DWARF
debugging information to that.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug admin/6105] New: fssv0o

[Ian Lance Taylor]

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

Re: [osol-discuss] Re: GNU ld -shared fails to link filtered symbols on Solaris

[Ian Lance Taylor]

[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.
 
  You're rewriting history, ELF was invented by UNIX System Laboratories.
 
 Can you prove that please?
 
 The first time I heard about ELF was with a talk held by Bill Joy on a Sun 
 user 
 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
closely based on the shared library implementation Sun used with the
a.out object file format in SunOS 4.

To me it seems that Sun developed the basic ideas, and ATT Unix
System Laboratories codified it into a complete standard.  A
particular idea which ATT added which was not in SunOS was the
separation of sections and segments.

Either way, it's really irrelevant to the original point.  Many people
other than Sun use ELF.  The registry of ELF numbers is held at SCO.
There is an ELF ABI group which has meet occasionally with
representatives from many companies.  Sun is free to extend ELF using
the defined extension capability, and that is what they have done.
Extensions written at Sun do not automatically become part of the ELF
standard.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [osol-discuss] Re: GNU ld -shared fails to link filtered symbols on Solaris

[Ian Lance Taylor]

[EMAIL PROTECTED] (Joerg Schilling) writes:

 Ian Lance Taylor ian@airs.com 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
  closely based on the shared library implementation Sun used with the
  a.out object file format in SunOS 4.
 
 
 This is definitely a wrong interpretation:

And yet that paragraph is, I believe, completely correct.  You didn't
dispute anything I said in it.

I won't reply further on this thread, since it is pointless.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: BUG elf32-i386 R_386_PC32 done wrong

[Ian Lance Taylor]

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 conform to the rel reloc formula *and*
 remove the requirement that .o files contain -4 at all those
 locations, which must be a continuing source of shame and
 embarrassment to writers of existing Linux compilers (nasm, C,
 etc).  Note that if ld coughs up its own -4 (per the formula I
 posted), all the existing .o/.so files would still link -- the
 -4 is a *constant* in the hardware-based formula and its
 presence in those .o/.so files should properly be ignored [so
 correct input files with any arbitrary value (e.g., 0) in those
 locations would also link].

If you ignore the contents of the .o file, then how do you propose to
handle the assembler code
call foo + 16
?

With the ELF ABI as designed and implemented, it is easy.  This type
of code can arise when the compiler implements alternate entry points
for functions: one external to the file and one internal.


 Notice Ian gave no rationale beyond what I might call This is
 the way we do it and Some ABI document covers us, as if any
 document changes how existing processors work.

We have an ABI so that all tools agree on the processing of i386 ELF
input files.  The ABI was written at ATT, the designers of the ELF
format, back in 1990 when the ELF object file format was first
designed.  In order for tools to interoperate, they must all implement
the same ABI.  And they do.  And that ABI says that R_386_PC32 is
implemented by adding the offset from the address to the contents of
the four byte field.  There is no -4 in the formula.

Note that 1990, when these rules were laid down, was before the Linus
had even started working on the Linux kernel, and long before the
Linux kernel supported ELF (Linux originally used the a.out object
file format).  So when you describe this as a Linux issue, you just
sound ignorant of history.  There are several systems besides Linux
which implement the i386 ELF ABI, and .o files for those systems all
interoperate correctly.


 From what we see in this thread of posts, will they have nothing
 credible that makes any sense -- other than some ABI doc says
 it's OK?  The enquiring public will want more substance than
 that.

OK, now you're just being a troll.


 Why do Linux developers appear to want to keep correct .o files
 (no -4 constants in there) out of the Linux environment?  Is the
 intent to keep quality software out of the Linux environment?  
 The larger computing world outside Linux/Sun, etc, also has
 smart people producing useful object files -- in business, math,
 science, you name it.  But ld does not know how to link them!

If those object files are ELF, then ld knows how to link them.  If
they are not ELF, then ld follows the rules appropriate for the object
file format.


 What message are you sending?  

That we know how to follow published standards and interoperate with
other tools.


 Is the message that objcopy writers now must also go in and
 insert the -4's in .text sections when converting from .obj to
 .o?  All because ld can't find its own -4?  [Free gift, cut and
 paste any -4 in this post and put it in ld source code!] 

Is that the context of all this babble?  You want to convert from .obj
files, presumably in the Windows PE/COFF object file format, to object
files in the ELF file format?  If you want to do that conversion, then
subtracting 4 from the contents of the section for PC relative relocs
is the least of the issues you are going to have to deal with.

Or, if you have a compiler which generates PE/COFF and you want to
generate ELF, then just produce assembly code and feed it into an ELF
assembler.  The right thing will happen.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: BUG elf32-i386 R_386_PC32 done wrong

[Ian Lance Taylor]

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 with a
fully statically linked program.

 So, is it safe to assume that attempting the conversion using ld alone
 will not produce a working ELF file in our case?  That instead we
 should use objcopy to produce the final file?

Yes.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: BUG elf32-i386 R_386_PC32 done wrong

[Ian Lance Taylor]

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
i386 Processors.

In typical use, the .o file will contain a 0xfffc in the four
bytes affected by R_386_PC32.  R_386_PC32 is defined to add the PC
relative offset from the start of the 4 byte field to the existing
contents of the 4 byte field.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: ld unwilling to find libs in configured paths

[Ian Lance Taylor]

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_PATH are set correctly. ld can
 link a lib correctly if the path is specified with -L. ldconfig -p
 prints out the correct paths to the problematic libs, and recreating
 the cache doesn't change the situation. I installed binutils 2.17 (from
 ftp.kernel.org) and the newest libtool (for the case that it is somehow
 related to ld's internals) but nothing changed. If it's not the usual
 configuration issues, what else can be missing?

I know this is confusing, but ld (not ld.so) does not use ld.so.conf
or LD_LIBRARY_PATH to find libraries specified on the command line.
It only uses the -L option.  When invoked from gcc, the gcc driver
itself will convert the environment variable LIBRARY_PATH (not
LD_LIBRARY_PATH) to -L options to pass to the linker.  The linker
itself ignores LIBRARY_PATH.

ldconfig tells you what ld.so will do, not what ld will do.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: libiberty vasprintf bug, doesn't handle long longs

[Ian Lance Taylor]

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 needs a full overhaul for C99.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: gprof : histogram records

[Ian Lance Taylor]

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 stored?
 (list, vector..?)

The gprof program is only prepared to see a single histogram record in
a gmon.out file.  So I think it is fairly safe to assume that a
gmon.out file will have only one histogram.

More precisely, gprof can use more than histogram, but they must cover
the same range of the program--same low PC, high PC, number of bins,
and profiling rate.  Support multiple histograms over the same
executable space is intended to let you generate multiple gmon.out
files from a single executable and combine them in a single gprof run.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug gas/847] New: Error: Zero-length symbol is illegal

[Ian Lance Taylor]

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 stdin' when input comes from stdin.
 
 Hmm, well the documentation does also say that the feature is only
 supported for backwards compatibility and may go away in the future.
 
 Still a patch for this problem seems fairly straight forward.
 
 Jan, Ian - what do you think of this ?
 
 Cheers
Nick
 
 gas/ChangeLog
 2005-04-15  Nick Clifton  [EMAIL PROTECTED]
 
   PR gas/847
   * read.c (s_app_file): Call tc_convert_file_name, if defined,
   before s_app_file_string.
   * config/tc-ia64.c (ia64_convert_file_name): Define.  Convert
   empty file names into stdin.
   * config/tc-ia64.h (tc_convert_file_name): Define.

Why does ia64_canonicalize_symbol_name reject a symbol with no name?
ELF permits them.  Perhaps there are places which call
canonicalize_symbol_name which want to reject empty symbol names, but
I don't see why they should be rejected in canonicalize_symbol_name
itself.

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system

[Ian Lance Taylor]

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 source code, it never has any information about xcoff,
 but in other source code like xcoff.h, it has some xcoff information, I
 donot know what I need to configure to support xcoff format. any idea?

configure with --target rs6000-ibm-aix

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system

[Ian Lance Taylor]

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 could help me with this?

Yes, it is possible, but it is not particularly easy if you are not
familiar with this kind of thing.

If you have not done so already, you will need to download cygwin--see
http://cygwin.com/

That will give you an objdump, but one that only supports PE COFF.
You will need to build your own version of the binutils for the
rs6000-aix target.  You can do this using cygwin.  Download the
binutils sources from, and follow the directions.
http://sourceware.org/binutils/

Ian


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils