Re: Fix for s390_elf_cons.

Re: Fix for s390_elf_cons.

[Martin Schwidefsky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

>This leaves me wondering why your plt relocs are marked pcrel.  It seems
>to me that they ought to be non-pcrel since you are already subtracting
>off a location-relative value with "-.LT0_0".  Alternatively, the correct
>syntax for a pc-relative relocation would be
>
>    .long     printk@PLT + (. - .LT0_0)
>
>since a pc-relative reloc implicitly subtracts "." from the symbol value.

Hmm, but .LT0_0 is a local label for the start of the literal pool. What
you have is

     .long (printk@PLT - .) + (. - .LT0_0)

The second part is an absolute addend and the first part is the pc relative
distance to the plt of printk. Does this makes sense?

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com

Re: Fix for s390_elf_cons.

[Alan Modra]

On Mon, Jul 30, 2001 at 08:38:43PM +0200, Martin Schwidefsky wrote:
> 
> >This leaves me wondering why your plt relocs are marked pcrel.  It seems
> >to me that they ought to be non-pcrel since you are already subtracting
> >off a location-relative value with "-.LT0_0".  Alternatively, the correct
> >syntax for a pc-relative relocation would be
> >
> >    .long     printk@PLT + (. - .LT0_0)
> >
> >since a pc-relative reloc implicitly subtracts "." from the symbol value.
> 
> Hmm, but .LT0_0 is a local label for the start of the literal pool. What
> you have is
> 
>      .long (printk@PLT - .) + (. - .LT0_0)
> 
> The second part is an absolute addend and the first part is the pc relative
> distance to the plt of printk. Does this makes sense?

Somewhat :)  I'm claiming that the subtraction of the current location is
implicit since you are using a pc-relative relocation.

Consider an analogy with pcrel call insns on many architectures.  We
write "call foo", which generates a pcrel reloc against foo with an
implicit subtraction of ".".  We don't write "call foo - .".  On x86,
which uses a pcrel plt reloc, we have "call foo@PLT" too, not
"call foo@PLT - ."  This extends to ".long foo@PLT" if you want a
pcrel plt reloc.

Hmm, thinking about it some more, you do want pcrel .plt relocs, it's
just that the syntax you are using is a little unusual.

Alan

Re: Fix for s390_elf_cons.

[Martin Schwidefsky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

>In that case: Martin, shall I commit the patch?
Yes, please do so.

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com

Re: Fix for s390_elf_cons.

[Martin Schwidefsky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

>Somewhat :)  I'm claiming that the subtraction of the current location is
>implicit since you are using a pc-relative relocation.
>
>Consider an analogy with pcrel call insns on many architectures.  We
>write "call foo", which generates a pcrel reloc against foo with an
>implicit subtraction of ".".  We don't write "call foo - .".  On x86,
>which uses a pcrel plt reloc, we have "call foo@PLT" too, not
>"call foo@PLT - ."  This extends to ".long foo@PLT" if you want a
>pcrel plt reloc.

Yes in the case of a call instruction it makes sense. We make use of
the same notation for the brasl instruction in the 64 bit assembler.
It makes sense because the instructions gives you the hint that you
are dealing with an implicit "- .". In the case of .long you don't
have that hint. And a ".long printk@PLT + . - .LT0_0" is somewhat
harder to understand than ".long printk@PLT - .LT0_0". The pseudo
op .long is by itself absolute.

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com

Fix for s390_elf_cons.

[Martin Schwidefsky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

Hi,
Andreas complained that binutils-2.11.90.0.24 doesn't work on s390/s390x.
Well he is right. The problem is that the behaviour of fixup_segment has
changed a bit.  The solution is to pass false for pcrel on the call to
fix_new_exp in s390_elf_cons. Then the missing pc relative conversion in
fixup_segment are done again.

blue skies,
   Martin

2001-07-29  Martin Schwidefsky  <schwidefsky@de.ibm.com>

     * config/tc-s390.c (s390_elf_cons): Correct fixups for PLT
     relocations.

(See attached file: elf_cons.diff)

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com

[-- Attachment #2: elf_cons.diff --]
[-- Type: text/x-diff, Size: 720 bytes --]

diff -urN src/gas/config/tc-s390.c src-s390/gas/config/tc-s390.c
--- src/gas/config/tc-s390.c	Thu Jul 26 21:07:01 2001
+++ src-s390/gas/config/tc-s390.c	Sun Jul 29 23:40:08 2001
@@ -943,8 +943,10 @@
 			reloc_howto->name, nbytes);
 	      where = frag_more (nbytes);
 	      md_number_to_chars (where, 0, size);
-	      fix_new_exp (frag_now, where - frag_now->fr_literal, 
-			   size, &exp, reloc_howto->pc_relative, reloc);
+	      /* To make fixup_segment do the pc relative conversion the
+		 pcrel parameter on the fix_new_exp call needs to be false.  */
+	      fix_new_exp (frag_now, where - frag_now->fr_literal,
+			   size, &exp, false, reloc);
 	    }
 	  else
 	    as_bad (_("relocation not applicable"));

Re: Fix for s390_elf_cons.

[H . J . Lu]

On Sun, Jul 29, 2001 at 11:53:07PM +0200, Martin Schwidefsky wrote:
> 
> Hi,
> Andreas complained that binutils-2.11.90.0.24 doesn't work on s390/s390x.
> Well he is right. The problem is that the behaviour of fixup_segment has
> changed a bit.  The solution is to pass false for pcrel on the call to
> fix_new_exp in s390_elf_cons. Then the missing pc relative conversion in
> fixup_segment are done again.
> 

Could you please also provide a patch for the gas testcase? I did verify
binutils-2.11.90.0.24 passed "make check" as cross build to s390-linux
and s390x-linux. We should be able to catch those kinds of bugs in the
gas testcase. Please check out the thread:

http://sources.redhat.com/ml/binutils/2001-07/msg00471.html

Thanks.


H.J.

Re: Fix for s390_elf_cons.

[Alan Modra]

On Sun, Jul 29, 2001 at 11:53:07PM +0200, Martin Schwidefsky wrote:
> 
> Andreas complained that binutils-2.11.90.0.24 doesn't work on s390/s390x.
> Well he is right. The problem is that the behaviour of fixup_segment has
> changed a bit.

Hmm, I guess that's this change:

2001-06-27  Alan Modra  <amodra@bigpond.net.au>
	* write.c (fixup_segment <Difference of 2 syms same seg>): Don't
	subtract MD_PCREL_FROM_SECTION for 68k.
	(fixup_segment <Difference of 2 syms different seg>): Only fudge
	by adding MD_PCREL_FROM_SECTION for 68k or if not already pcrel.

Curiousity got the better of me, and I built an s390-linux cross-
compiler to see why this would affect you.  Output from a -fPIC
compile showed:

[snip]
.LC0:
        .string "blah"
[snip]
.LT0_0:
.LC1:
        .long   .LC0-.LT0_0
.LC2:
        .long   printk@PLT-.LT0_0
[snip]

This leaves me wondering why your plt relocs are marked pcrel.  It seems
to me that they ought to be non-pcrel since you are already subtracting
off a location-relative value with "-.LT0_0".  Alternatively, the correct
syntax for a pc-relative relocation would be

	.long	printk@PLT + (. - .LT0_0)

since a pc-relative reloc implicitly subtracts "." from the symbol value.

Alan

Re: Fix for s390_elf_cons.

[Andreas Jaeger]

"Martin Schwidefsky" <schwidefsky@de.ibm.com> writes:

> Hi,
> Andreas complained that binutils-2.11.90.0.24 doesn't work on s390/s390x.
> Well he is right. The problem is that the behaviour of fixup_segment has
> changed a bit.  The solution is to pass false for pcrel on the call to
> fix_new_exp in s390_elf_cons. Then the missing pc relative conversion in
> fixup_segment are done again.

Has this issue now been resolved?  I didn't see the patch committed
and from the discussion it's not clear to me what should be done now.

Andreas
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7b9PNOJpWPMJyoSYRAmD2AJ9QIJnqDQYdS5N4hXCthH4RQ8GsQACeIuDP
vx41PB5SxZkW4Mru5itgEac=
=ml4Z
-----END PGP SIGNATURE-----From ica2_ts@csv.ica.uni-stuttgart.de Tue Aug 07 05:38:00 2001
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
To: binutils@sources.redhat.com
Subject: Re: [PATCH] Fix MIPS disassembler's register names output
Date: Tue, 07 Aug 2001 05:38:00 -0000
Message-id: <20010807143751.A3673@rembrandt.csv.ica.uni-stuttgart.de>
References: <20010721235635.H16278@rembrandt.csv.ica.uni-stuttgart.de>
X-SW-Source: 2001-08/msg00105.html
Content-length: 636

Thiemo Seufer wrote:
[snip]
> 2001-07-21  Thiemo Seufer <seufer@csv.ica.uni-stuttgart.de>
> 
> 	/opcodes/ChangeLog
> 	* mips-dis.c (print_insn_arg): Don't use software integer registers
> 	for coprocessor registers.
> 	(get_mips_isa): Removed.
> 	(is_newabi): New function, checks if NewABI is used.
> 	(_print_insn_mips): Get distinction between old ABI and new ABI right.
> 
> 	/gas/testsuite/ChangeLog
> 	* mips/lb.d: Reflect disassembler output fixes.
> 	* mips/mips32.d: Likewise.
> 	* mips/mips64.d: Likewise. Typo.
> 	* mips/sb.d: Likewise.
> 	* mips/trunc.d: Likewise.

There were no objections, so I checked this in.


Thiemo

Re: Fix for s390_elf_cons.

[Alan Modra]

On Tue, Aug 07, 2001 at 01:41:00PM +0200, Andreas Jaeger wrote:
> "Martin Schwidefsky" <schwidefsky@de.ibm.com> writes:
> 
> > Hi,
> > Andreas complained that binutils-2.11.90.0.24 doesn't work on s390/s390x.
> > Well he is right. The problem is that the behaviour of fixup_segment has
> > changed a bit.  The solution is to pass false for pcrel on the call to
> > fix_new_exp in s390_elf_cons. Then the missing pc relative conversion in
> > fixup_segment are done again.
> 
> Has this issue now been resolved?  I didn't see the patch committed
> and from the discussion it's not clear to me what should be done now.

Since I was involved in the discussion, let me make it clear that I don't
have an objection to the patch itself.  It's OK to commit in that it does
the right thing interpreting the, to my mind weird, s390 assembly syntax.
I suppose it's too late to change the syntax now.

Alan

Re: Fix for s390_elf_cons.

[Andreas Jaeger]

Alan Modra <amodra@bigpond.net.au> writes:

> On Tue, Aug 07, 2001 at 01:41:00PM +0200, Andreas Jaeger wrote:
> > "Martin Schwidefsky" <schwidefsky@de.ibm.com> writes:
>> 
>> > Hi,
>> > Andreas complained that binutils-2.11.90.0.24 doesn't work on s390/s390x.
>> > Well he is right. The problem is that the behaviour of fixup_segment has
>> > changed a bit.  The solution is to pass false for pcrel on the call to
>> > fix_new_exp in s390_elf_cons. Then the missing pc relative conversion in
>> > fixup_segment are done again.
>> 
>> Has this issue now been resolved?  I didn't see the patch committed
>> and from the discussion it's not clear to me what should be done now.
>
> Since I was involved in the discussion, let me make it clear that I don't
> have an objection to the patch itself.  It's OK to commit in that it does
> the right thing interpreting the, to my mind weird, s390 assembly syntax.
> I suppose it's too late to change the syntax now.

In that case: Martin, shall I commit the patch?

Thanks Alan,
Andreas
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7b+dXOJpWPMJyoSYRAshsAJ9kC9sU1j//EkcIV1KOnBHuqynv1wCfZnY0
TwIWmATsdHJl4lr0YOSUAgM=
=wnG0
-----END PGP SIGNATURE-----From Dainis@fortech.lv Tue Aug 07 06:51:00 2001
From: Dainis Strupis <Dainis@fortech.lv>
To: "'binutils@sources.redhat.com'" <binutils@sources.redhat.com>
Subject: Changing default memory segments
Date: Tue, 07 Aug 2001 06:51:00 -0000
Message-id: <620C734D5719D5118ED500306E018727078A29@walker.fortech.lv>
X-SW-Source: 2001-08/msg00109.html
Content-length: 769

Is there any way to change the default segments used by the GCC compiler.
I am working on an embedded system with several types of ROM and RAM 
Internal and External - different speeds, static Ram and DRAM, etc.)and
I am often shuffling code and data into specific memory regions for improved
performance.
 
I found only one way to put code (.text) segment from C files,
in differem memory locatins, by change in assembler file
or object file(if assembler file not aivailable) ".text" to .textsram".

What is right syntax for "ld"  script for putting code (.text) segment from
several files to other memory region (SRAM but not DRAM) without change segment
name ?


Best regards
Dainis Strupis
dainis@saftehnika.com

p.s.
problem is actual for  GCC 2.7 mips-lsi-elf