[Bug binutils/20984] New: different DOT value in the 'same' place

2016-12-20 Thread pangbw at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=20984

Bug ID: 20984
   Summary: different DOT value in the 'same' place
   Product: binutils
   Version: 2.22
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: pangbw at gmail dot com
  Target Milestone: ---

Created attachment 9708
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9708&action=edit
linker script

Steps to show the issue:
1. cat t.c

#include 

extern char tdata_size [];
extern char tdata_tbss_size [];
extern char tdata_tbss_size2 [];
extern char tdata_tbss_size3 [];

__thread int tls = 0;

int main()
{
  printf("Hello DOT. %d %d %d %d\n",
 tdata_size, tdata_tbss_size, tdata_tbss_size2, tdata_tbss_size3);
  return 0;
}

2. tdata_size, tdata_tbss_size, tdata_tbss_size2 and tdata_tbss_size3 are
defined in the attached link script x.link:

tdata_start = .;
  .tdata  : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
  tdata_size = . - tdata_start;
  .tbss   : {
  *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon)
  tbss_end = .;
  }
  tdata_tbss_size = . - tdata_start;
  tdata_tbss_size2 = tbss_end - tdata_start;
  tdata_tbss_size3 = SIZEOF(.tdata) + SIZEOF(.tbss);


3. gcc -static t.c -Wl,-T x.link
4. ./a.out
Hello DOT. 34 34 90 88

I got this result on Ubuntu precise (12.04.5 LTS), also got the slightly
different result on another different Linux host.

I can understand the difference between tdata_tbss_size2 and tdata_tbss_size3
is caused by alignment, but why tdata_tbss_size is different than
tdata_tbss_size2?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/23154] New: invalid register expression

2018-05-09 Thread pangbw at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=23154

Bug ID: 23154
   Summary: invalid register expression
   Product: binutils
   Version: 2.30
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: pangbw at gmail dot com
  Target Milestone: ---

For assembly code:
$ cat x.s
addis   %r5,%r1,2
addis   %r5,%r0,2
addis   5,0,2

A warning will be emited for line 2 but not for line 1 and line 3:
$ as -a32 -mppc -many -mbig -o x.o x.s
x.s: Assembler messages:
x.s:2: Warning: invalid register expression

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/23154] invalid register expression

2018-05-09 Thread pangbw at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=23154

Baoshan  changed:

   What|Removed |Added

 CC||pangbw at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/23154] invalid register expression

2018-05-09 Thread pangbw at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=23154

--- Comment #2 from Baoshan  ---
(In reply to Andreas Schwab from comment #1)
> For the second line, the second operand is not a register but the constant 0
> (equivalent to lis %r5,2).

Do you mean even it is written as %r0 it is treated as constant 0? 
if so in line 3, the second operand is written explicity as constant 0, why it
is OK?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/23154] invalid register expression

2018-05-09 Thread pangbw at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=23154

Baoshan  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #3 from Baoshan  ---
(In reply to Andreas Schwab from comment #1)
> For the second line, the second operand is not a register but the constant 0
> (equivalent to lis %r5,2).


Do you mean even it is written as %r0 it is treated as constant 0? 
if so in line 3, the second operand is written explicity as constant 0, why it
is OK?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/23154] invalid register expression

2018-05-09 Thread pangbw at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=23154

--- Comment #5 from Baoshan  ---
(In reply to Andreas Schwab from comment #4)
> That's the point of the warning, an operand written as register but isn't
> one.

Is there any place/document I can check that's saying %r0 can not be used in
this way?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/23189] New: bad symbol index: ffffffff

2018-05-16 Thread pangbw at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=23189

Bug ID: 23189
   Summary: bad symbol index: 
   Product: binutils
   Version: 2.30
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: pangbw at gmail dot com
  Target Milestone: ---

Created attachment 11020
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11020&action=edit
the linker script

I am seeing bad relocation is created for hidden symbols with ld 2.30, there is
no problem with 2.29 with the same test case and the same procedure:

$ cat t.c
extern int *__hidden_sym;
int *foo()
{
  return __hidden_sym;
}

$ gcc -c -fpic t.c -o t.sho
ld -m elf_x86_64 -shared -o libt.so t.sho -Tx.link

$ readelf -r libt.so

Relocation section '.rela.dyn' at offset 0x1e0 contains 1 entries:
  Offset  Info   Type   Sym. ValueSym. Name +
Addend
00200320  0006 R_X86_64_GLOB_DAT bad symbol index: 

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/23189] bad symbol index: ffffffff

2018-05-16 Thread pangbw at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=23189

Baoshan  changed:

   What|Removed |Added

 CC||pangbw at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/23189] bad symbol index: ffffffff

2018-05-17 Thread pangbw at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=23189

--- Comment #2 from Baoshan  ---
(In reply to Nick Clifton from comment #1)
> Hi Baoshan,
> 
>   I cannot reproduce this problem using today's mainline development
>   sources.  Please could you check and see if the problem still exists
>   for you ?
> 
> Cheers
>   Nick

Hi Nick,

I don't see any difference with the mainline development sources, I am using
the code from: git://sourceware.org/git/binutils-gdb.git

Can you reproduce the issue with 2.30?

Thanks,
Baoshan

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/23189] bad symbol index: ffffffff

2018-05-17 Thread pangbw at gmail dot com 
https://sourceware.org/bugzilla/show_bug.cgi?id=23189

--- Comment #3 from Baoshan  ---
I checked a little bit of the code, what I see for this issue the difference
between 2.29 and 2.30 is that:
For 2.29 the checking if a symbol is hidden is before the calling of function
elf_x86_64_convert_load_reloc, but in 2.30 they are in opposite order.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils