This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

.rodata segment


Hello,

this is probably more a gcc question, but how can I force static data to
end up in .data and not (as is the default with gcc-2.95.2) in the
.rodata segment?

Thanks,
Arno

* Ulrich Drepper <drepper@cygnus.com>:

|> doesn't have standalone atexit, this is the problem?
| 
| This is exactly what is intended and no, it is no problem.  If you see problems
| something else is wrong on your side.

Yes, else can be either binutils or gcc. I have found that
gcc calls /usr/lib/gcc-lib/i386-linux/2.95.2/collect2 as ld
instead of /usr/bin/ld. I replaced that file with binutils'
ld, but same error. So I'm totally lost, but it is better
that I'm not alone, and someone else has this problem on
totally different platform.





> From: Andreas Jaeger <aj@suse.de>
> Date: 07 Mar 2001 14:48:08 +0100

> We didn't handle some relocations correctly for x86-64, I've committed
> the appended patch to both branches after testing on both branches.

I see the same hunk of code in several targets, but rarely a
line indicating what situations the code reflects.  If you
happen to know and have this in clear memory, how about adding a
descriptive comment line or two?  See the DWARF comment.  I'll
help with an example which should match here.

		   /* When creating a shared library, we can have an
		      ordinary relocation for a symbol defined in a shared
		      library (perhaps the one we create).  We then make
		      the relocation value zero, as it will be added into
		      the relocation addend in this shared library.
		      FIXME: Not sure this example covers the
		      h->elf_link_hash_flags test.  */

> +		  || (info->shared
> +		      && ((! info->symbolic && h->dynindx != -1)
> +			  || (h->elf_link_hash_flags
> +			      & ELF_LINK_HASH_DEF_REGULAR) == 0)
> +		      && ( r_type == R_X86_64_8 ||
> +			   r_type == R_X86_64_16 ||
> +                           r_type == R_X86_64_32 ||
> +			   r_type == R_X86_64_64 ||
> +                           r_type == R_X86_64_PC16 ||
> +			   r_type == R_X86_64_PC32)
> +                      && ((input_section->flags & SEC_ALLOC) != 0
> +                          /* DWARF will emit R_X86_64_32 relocations in its
> +                             sections against symbols defined externally
> +                             in shared libraries.  We can't do anything
> +                             with them here.  */
> +                          || ((input_section->flags & SEC_DEBUGGING) != 0
> +			      && (h->elf_link_hash_flags
> +				  & ELF_LINK_HASH_DEF_DYNAMIC) != 0))))

brgds, H-P




Hi Guys,

  I have checked in a patch to update the copyright notices on the
  files in the GAS directory, and incidentally, fix a few typos in the
  ChangeLogs.

Cheers
        Nick





binutils doesn't know s390/s390x:

# ./config.sub s390-linux
Invalid configuration `s390-linux': machine `s390' not recognized
# ./config.sub s390x-linux
Invalid configuration `s390x-linux': machine `s390x' not recognized

Here is a patch. I can build the cross assembler to s390-linux now.


H.J.
----
2001-03-09  H.J. Lu <hjl@gnu.org>

	* config.sub: Recognize s390/s390x as valid $basic_machine.

Index: config.sub
===================================================================
RCS file: /work/cvs/gnu/binutils/config.sub,v
retrieving revision 1.17
diff -u -p -r1.17 config.sub
--- config.sub	2001/02/10 23:40:35	1.17
+++ config.sub	2001/03/09 22:07:41
@@ -234,7 +234,7 @@ case $basic_machine in
 		| mips16 | mips64 | mipsel | mips64el \
 		| mips64orion | mips64orionel | mipstx39 | mipstx39el \
 		| mips64vr4300 | mips64vr4300el | mips64vr4100 | mips64vr4100el \
-		| mips64vr5000 | miprs64vr5000el | mcore \
+		| mips64vr5000 | miprs64vr5000el | mcore | s390 | s390x \
 		| sparc | sparclet | sparclite | sparc64 | sparcv9 | v850 | c4x \
 		| thumb | d10v | d30v | fr30 | avr | openrisc)
 		basic_machine=$basic_machine-unknown




Hi Guys,

  I noticed that GAS for the arm-coff port does not set the correct
  machine number in the object files that it creates.  It was ignoring
  the fact that the default value cpu_variant might include some of
  the new architecture variants.

  The patch below fixes it, but I am posting it here first, before
  applying it, in case anyone has any questions or concerns about it.
  I have run the usual tests and nothing untoward has turned up, but I
  wanted to give people a heads up before changing something that
  might possibly have unforeseen consequences.

  It is also slightly worrying that the arm-elf port never seems to
  set the machine number at all, leaving it at zero.  I have not yet
  investigated why this should be so.

Cheers
        Nick

2001-03-09  Nick Clifton  <nickc@redhat.com>

	* config/tc-arm.c (md_begin): Always set machine type based on
	cpu_variant.

Index: gas/config/tc-arm.c
===================================================================
RCS file: /cvs/src//src/gas/config/tc-arm.c,v
retrieving revision 1.75
diff -p -w -r1.75 tc-arm.c
*** tc-arm.c	2001/03/08 23:24:23	1.75
--- tc-arm.c	2001/03/10 01:04:02
*************** md_begin ()
*** 6513,6520 ****
      }
  
    /* Catch special cases.  */
-   if (cpu_variant != (FPU_DEFAULT | CPU_DEFAULT))
-     {
        if (cpu_variant & ARM_EXT_XSCALE)
  	mach = bfd_mach_arm_XScale;
        else if (cpu_variant & ARM_EXT_V5E)
--- 6513,6518 ----
*************** md_begin ()
*** 6535,6541 ****
  	}
        else if (cpu_variant & ARM_EXT_LONGMUL)
  	mach = bfd_mach_arm_3M;
-     }
  
    bfd_set_arch_mach (stdoutput, TARGET_ARCH, mach);
  }
--- 6533,6538 ----

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]