public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Fu, Chao-Ying" <fu@mips.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>,
	       Richard Sandiford	<rdsandiford@googlemail.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>,
	       "Fuhler, Rich"	<rich@mips.com>,
	"Lau, David" <davidlau@mips.com>,
	       "Mills, Kevin"	<kevinm@mips.com>,
	"Garbacea, Ilie" <ilie@mips.com>,
	       Catherine Moore	<clm@codesourcery.com>,
	       Nathan Sidwell <nathan@codesourcery.com>,
	       Joseph Myers <joseph@codesourcery.com>,
	       Nathan Froyd <froydnj@codesourcery.com>
Subject: RE: [PATCH] MIPS: microMIPS ASE support
Date: Tue, 22 Feb 2011 20:12:00 -0000	[thread overview]
Message-ID: <7C6479EB2BF52547AC332FD6034646DA8495CBC4@exchdb01.mips.com> (raw)
In-Reply-To: <alpine.DEB.1.10.1102111905400.20460@tp.orcam.me.uk>

Maciej W. Rozycki wrote:
> 
>  Chao-ying, there are a couple of questions for you 
> throughout -- would 
> you please give them a thought?  And anyone, of course, 
> please feel free 
> to comment as you like.
> 
> > > +static char *
> > > +micromips_label_name (void)
> > > +{
> > > +  char *p = micromips_target_name;
> > > +  char symbol_name_temporary[24];
> > > +  unsigned long l;
> > > +  int i;
> > > +
> > > +  if (*p)
> > > +    return p;
> > > +
> > > +  i = 0;
> > > +  l = micromips_target_label;
> > > +#ifdef LOCAL_LABEL_PREFIX
> > > +  *p++ = LOCAL_LABEL_PREFIX;
> > > +#endif
> > [...]
> > > +int
> > > +mips_label_is_local (const char *name)
> > > +{
> > > +  return strchr (name, MICROMIPS_LABEL_CHAR) != NULL;
> > > +}
> > 
> > Why is this change needed?  The default local-label 
> detection should be
> > enough for ELF targets, which always have a LOCAL_LABEL_PREFIX.
> 
>  I fail to see a justification, so I have removed this function.  
> Chao-ying, do you have anything to add?

  I don't recall that I wrote this code.  So, you may remove it.

> 
> > > +  /* For microMIPS PC relative relocations, we cannot 
> convert it to
> > > +     against a section.  If we do, it will mess up the 
> fixp->fx_offset.  */
> > >    if (fixp->fx_r_type == BFD_RELOC_VTABLE_INHERIT
> > > -      || fixp->fx_r_type == BFD_RELOC_VTABLE_ENTRY)
> > > +      || fixp->fx_r_type == BFD_RELOC_VTABLE_ENTRY
> > > +      || fixp->fx_r_type == BFD_RELOC_MICROMIPS_7_PCREL_S1
> > > +      || fixp->fx_r_type == BFD_RELOC_MICROMIPS_10_PCREL_S1
> > > +      || fixp->fx_r_type == BFD_RELOC_MICROMIPS_16_PCREL_S1)
> > 
> > "to be against a section".  That's not a helpful comment though.
> > _How_ will it mess up fixp->fx_offset?  Give the reader a clue why
> > the problem applies to BFD_RELOC_MICROMIPS_16_PCREL_S1 but not
> > to something like BFD_RELOC_16_PCREL_S2.
> 
>  I have failed to spot any problems with this hunk reverted 
> and I'm not 
> sure what I should be looking for.  Therefore I feel a bit 
> uneasy about 
> removing it and only rephrased the comment without actually 
> changing its 
> meaning.  Chao-ying, do you have anything to add?

  I added this code to avoid GAS errors when compiling Linux kernel for microMIPS.
Ex:
  mipsisa32r2-linux-gnu-gcc -Wp,-MD,kernel/.rtmutex.o.d  -nostdinc -isystem /hom
e/fu/dev/binutils3/build-linux-20090506/tools/lib/gcc/mipsisa32r2-linux-gnu/4.4.
0/include -D__KERNEL__ -Iinclude  -include include/linux/autoconf.h -Wall -Wunde
f -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -O2  -mabi
=32 -G 0 -mno-abicalls -fno-pic -pipe -ffreestanding -EL -UMIPSEB -U_MIPSEB -U__
MIPSEB -U__MIPSEB__ -UMIPSEL -U_MIPSEL -U__MIPSEL -U__MIPSEL__ -DMIPSEL -D_MIPSE
L -D__MIPSEL -D__MIPSEL__ -march=mips32r2 -Wa,-mips32r2 -Wa,--trap -Iinclude/asm
-mips/mach-sim -Iinclude/asm-mips/mach-generic -mmicromips -fomit-frame-pointer
-g  -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -mmicro
mips    -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(rtmutex)"  -D"KBUILD_
MODNAME=KBUILD_STR(rtmutex)" -c -o kernel/.tmp_rtmutex.o kernel/rtmutex.c
{standard input}: Assembler messages:
{standard input}:3030: Error: relocation overflow
{standard input}:3125: Error: relocation overflow
{standard input}:3213: Error: relocation overflow
{standard input}:3408: Error: relocation overflow
make[1]: *** [kernel/rtmutex.o] Error 1

  A simple case is as follows.
<597> # cat 2.s
                .set    push
        .set    noat
        .set    mips3
        .space  1<<10
1:      ll      $6, 0($2)                       # __cmpxchg_u32
        bne     $6, $0, 2f
        .set    mips0
        move    $1, $3
        .set    mips3
        sc      $1, 0($2)
        beqz    $1, 3f
2:
        .subsection 2
3:      b       1b
        .previous
        .set    pop

  I kind of forgot my debug process to come out with the solution.
Maybe if we use the section as the target, R_MICROMIPS_PC7_S1 will lead to
incorrect checking for overflow.
Ex: (write.c)
static void
adjust_reloc_syms (bfd *abfd ATTRIBUTE_UNUSED,
                   asection *sec,
                   void *xxx ATTRIBUTE_UNUSED)
{
  segment_info_type *seginfo = seg_info (sec);
  fixS *fixp;
...
        /* We refetch the segment when calling section_symbol, rather
           than using symsec, because S_GET_VALUE may wind up changing
           the section when it calls resolve_symbol_value.  */
        fixp->fx_offset += S_GET_VALUE (sym); <----- THIS WILL BE TOO BIG, if we use the section.
        fixp->fx_addsy = section_symbol (S_GET_SEGMENT (sym));
#ifdef DEBUG5
        fprintf (stderr, "\nadjusted fixup:\n");
        print_fixup (fixp);
#endif
      }

  dump_section_relocs (abfd, sec, stderr);
}

  Thanks!

Regards,
Chao-ying

  reply	other threads:[~2011-02-22 20:12 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18 18:19 [PATCH] MIPS: microMIPS and MCU ASE instruction set support Maciej W. Rozycki
2010-05-23 21:38 ` Richard Sandiford
2010-05-24 22:25   ` Fu, Chao-Ying
2010-05-26 19:47     ` Richard Sandiford
2010-06-01 14:21   ` Maciej W. Rozycki
2010-06-01 14:39     ` Catherine Moore
2010-06-01 22:04     ` Richard Sandiford
2010-06-01 22:47     ` Fu, Chao-Ying
2010-06-05  9:17     ` Richard Sandiford
2010-07-26 10:56   ` [PATCH] MIPS: microMIPS ASE support Maciej W. Rozycki
2010-07-26 13:25     ` Nathan Froyd
2010-07-26 13:53       ` Maciej W. Rozycki
2010-07-26 19:03     ` Richard Sandiford
2010-12-07  1:13       ` Maciej W. Rozycki
2010-12-12 14:59         ` Richard Sandiford
2010-12-14 13:30           ` Maciej W. Rozycki
2010-12-14 14:51             ` Richard Sandiford
2010-12-16 11:54               ` Maciej W. Rozycki
2010-12-18 10:26                 ` Richard Sandiford
2010-12-14 17:56             ` Joseph S. Myers
2010-12-16 15:28               ` Maciej W. Rozycki
2010-12-17 20:56             ` Fu, Chao-Ying
2010-12-18 10:09               ` Richard Sandiford
2011-01-02 11:36         ` Richard Sandiford
2011-02-21 15:35           ` Maciej W. Rozycki
2011-02-22 20:12             ` Fu, Chao-Ying [this message]
2011-02-22 20:19             ` Fu, Chao-Ying
2011-02-24 10:46               ` Maciej W. Rozycki
2011-02-26 11:41                 ` Richard Sandiford
2011-02-28 16:41                   ` Maciej W. Rozycki
2011-02-26  0:00             ` Maciej W. Rozycki
2011-03-13  9:23               ` Richard Sandiford
2011-07-25  7:49                 ` Richard Sandiford
2011-07-26  2:01                   ` Maciej W. Rozycki
2011-07-29  0:58                     ` Maciej W. Rozycki
2011-07-29 11:30                       ` Richard Sandiford
2011-07-29 22:52                         ` Maciej W. Rozycki
2011-02-26 11:36             ` Richard Sandiford
2011-07-26 14:00               ` Maciej W. Rozycki
2010-05-26 20:19 ` [PATCH] MIPS: microMIPS and MCU ASE instruction set support Richard Sandiford
2010-05-27 21:39 ` Richard Sandiford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7C6479EB2BF52547AC332FD6034646DA8495CBC4@exchdb01.mips.com \
    --to=fu@mips.com \
    --cc=binutils@sourceware.org \
    --cc=clm@codesourcery.com \
    --cc=davidlau@mips.com \
    --cc=froydnj@codesourcery.com \
    --cc=ilie@mips.com \
    --cc=joseph@codesourcery.com \
    --cc=kevinm@mips.com \
    --cc=macro@codesourcery.com \
    --cc=nathan@codesourcery.com \
    --cc=rdsandiford@googlemail.com \
    --cc=rich@mips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).