* RE: [CR16] Problem with TC_LINKRELAX_FIXUP
@ 2012-06-28 12:20 Jayant R. Sonar
2012-06-30 2:25 ` Alan Modra
0 siblings, 1 reply; 6+ messages in thread
From: Jayant R. Sonar @ 2012-06-28 12:20 UTC (permalink / raw)
To: binutils; +Cc: mr.swami.reddy, amodra, amodra
[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]
Renamed the attachments and resending them again.
Hope they won't be quarantined this time.
-----Original Message-----
From: Jayant R. Sonar
Sent: Thursday, June 28, 2012 5:38 PM
To: 'binutils@sourceware.org'
Cc: 'mr.swami.reddy@nsc.com'; 'amodra@bigpond.net.au'; 'amodra@gmail.com'
Subject: [CR16] Problem with TC_LINKRELAX_FIXUP
Hello,
On CR16 platform I am using Dhrystone application with uClinux kernel.
If I configure it as built-in driver it works fine. However, if in
configure it as loadable module, I get an unexpected behavior.
-----------------------------------------------------------------------
WORKING: Built-in driver output:
[ 0.570000] Starting SC1445x Dhrystone 'driver'
[ 0.580000] rwsem->wait_list is empty
[ 0.580000] head=0015e544 next=0015e544 prev=0015e544
FAILURE: Loadable module output:
[ 13.960000] Starting SC1445x Dhrystone 'driver'
[ 13.960000] rwsem->wait_list is NOT empty
[ 13.970000] head=00fd50bc next=00fd50b8 prev=00fd50b8
-----------------------------------------------------------------------
Problem:
As shown in above dump, Wait_list is supposed to be empty and addresses
of 'next' and 'prev' are expected to be same as 'head'. But in loadable
module, they are lesser than 'head' by 4.
I compared the readelf dumps of object files of these 2 configurations
(Dumps can be found attached with this mail).
I found following differences:
-----------------------------------------------------------------------
WORKING: Built-in driver output:
Relocation section '.rela.data' at offset 0x7fc contains 2 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000004 00000703 R_CR16_NUM32 00000000 _rwsem + 4
00000008 00000703 R_CR16_NUM32 00000000 _rwsem + 4
=================
FAILURE: Loadable module output:
Relocation section '.rela.data' at offset 0x7b8 contains 2 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000004 00000703 R_CR16_NUM32 00000000 _rwsem + 0
00000008 00000703 R_CR16_NUM32 00000000 _rwsem + 0
----------------------------------------------==================-------
Addend in case of non-working configuration is found to be zero where
as it is 4 in working configuration.
At following URL, I found a change in TC_LINKRELAX_FIXUP was made to
resolve non-code section fixups at assembly time:
http://sourceware.org/ml/binutils/2009-07/msg00035.html
If I revert this change, my problem gets solved. But then I start
getting same problem that Swami had reported earlier in the URL:
>> libstdc++.a(future.o)(.eh_frame); no .eh_frame_hdr table will be created.
(REF: http://sourceware.org/ml/binutils/2009-06/msg00463.html)
Can someone help me finding any other way by which this can be fixed?
Regards,
Jayant Sonar
[KPIT Cummins, Pune]
[-- Attachment #2: failure.txt --]
[-- Type: text/plain, Size: 6021 bytes --]
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: National Semiconductor's CR16
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 588 (bytes into file)
Flags: 0xb1
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 14
Section header string table index: 11
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 00007a 00 AX 0 0 4
[ 2] .rela.text RELA 00000000 0006ec 0000cc 0c 12 1 4
[ 3] .data PROGBITS 00000000 0000b0 00000c 00 WA 0 0 4
[ 4] .rela.data RELA 00000000 0007b8 000018 0c 12 3 4
[ 5] .bss NOBITS 00000000 0000bc 000000 00 WA 0 0 1
[ 6] .rodata.str1.2 PROGBITS 00000000 0000bc 00008c 01 AMS 0 0 2
[ 7] .modinfo PROGBITS 00000000 000148 00000c 00 A 0 0 2
[ 8] .debug_frame PROGBITS 00000000 000154 00006c 00 0 0 4
[ 9] .rela.debug_frame RELA 00000000 0007d0 000030 0c 12 8 4
[10] .comment PROGBITS 00000000 0001c0 000021 01 MS 0 0 1
[11] .shstrtab STRTAB 00000000 0001e1 000069 00 0 0 1
[12] .symtab SYMTAB 00000000 00047c 0001b0 10 13 24 4
[13] .strtab STRTAB 00000000 00062c 0000c0 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
There are no program headers in this file.
Relocation section '.rela.text' at offset 0x6ec contains 17 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000002 00000c13 R_CR16_IMM32 00000008 .LC3 + 0
0000000a 00001819 R_CR16_DISP24a 00000000 _printk + 0
00000010 00000d13 R_CR16_IMM32 00000002 .LC1 + 0
00000016 0000070d R_CR16_ABS24 00000000 _rwsem + 0
0000001c 00000713 R_CR16_IMM32 00000000 _rwsem + 0
00000028 00000e13 R_CR16_IMM32 0000002e .LC4 + 0
00000030 00001819 R_CR16_DISP24a 00000000 _printk + 0
00000034 0000070d R_CR16_ABS24 00000000 _rwsem + 0
0000003c 0000070d R_CR16_ABS24 00000000 _rwsem + 0
00000044 00000713 R_CR16_IMM32 00000000 _rwsem + 0
0000004c 00000f13 R_CR16_IMM32 0000004c .LC5 + 0
00000054 00001819 R_CR16_DISP24a 00000000 _printk + 0
00000060 00001013 R_CR16_IMM32 00000000 .LC0 + 0
0000006a 00001113 R_CR16_IMM32 00000066 .LC6 + 0
00000072 00001819 R_CR16_DISP24a 00000000 _printk + 0
00000024 00001216 R_CR16_DISP8 00000060 .L5 + 0
00000066 00001316 R_CR16_DISP8 00000026 .L2 + 0
Relocation section '.rela.data' at offset 0x7b8 contains 2 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000004 00000703 R_CR16_NUM32 00000000 _rwsem + 0
00000008 00000703 R_CR16_NUM32 00000000 _rwsem + 0
Relocation section '.rela.debug_frame' at offset 0x7d0 contains 4 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000014 00001403 R_CR16_NUM32 00000000 .Lframe0 + 0
00000018 00001503 R_CR16_NUM32 00000000 .LFB471 + 0
00000050 00001403 R_CR16_NUM32 00000000 .Lframe0 + 0
00000054 00001603 R_CR16_NUM32 00000068 .LFB472 + 0
There are no unwind sections in this file.
Symbol table '.symtab' contains 27 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS sc1445x_dhrystone.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 5
5: 00000000 0 SECTION LOCAL DEFAULT 6
6: 00000000 104 FUNC LOCAL DEFAULT 1 _sc1445x_dhrystone_init
7: 00000000 12 OBJECT LOCAL DEFAULT 3 _rwsem
8: 00000068 18 FUNC LOCAL DEFAULT 1 _sc1445x_dhrystone_exit
9: 00000000 0 SECTION LOCAL DEFAULT 7
10: 00000000 12 OBJECT LOCAL DEFAULT 7 ___mod_license3
11: 00000000 0 SECTION LOCAL DEFAULT 8
12: 00000008 0 NOTYPE LOCAL DEFAULT 6 .LC3
13: 00000002 0 NOTYPE LOCAL DEFAULT 6 .LC1
14: 0000002e 0 NOTYPE LOCAL DEFAULT 6 .LC4
15: 0000004c 0 NOTYPE LOCAL DEFAULT 6 .LC5
16: 00000000 0 NOTYPE LOCAL DEFAULT 6 .LC0
17: 00000066 0 NOTYPE LOCAL DEFAULT 6 .LC6
18: 00000060 0 NOTYPE LOCAL DEFAULT 1 .L5
19: 00000026 0 NOTYPE LOCAL DEFAULT 1 .L2
20: 00000000 0 NOTYPE LOCAL DEFAULT 8 .Lframe0
21: 00000000 0 NOTYPE LOCAL DEFAULT 1 .LFB471
22: 00000068 0 NOTYPE LOCAL DEFAULT 1 .LFB472
23: 00000000 0 SECTION LOCAL DEFAULT 10
24: 00000000 0 NOTYPE GLOBAL DEFAULT UND _printk
25: 00000000 104 FUNC GLOBAL DEFAULT 1 _init_module
26: 00000068 18 FUNC GLOBAL DEFAULT 1 _cleanup_module
No version information found in this file.
[-- Attachment #3: working.txt --]
[-- Type: text/plain, Size: 6021 bytes --]
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: National Semiconductor's CR16
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 656 (bytes into file)
Flags: 0xb1
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 14
Section header string table index: 11
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 00007a 00 AX 0 0 4
[ 2] .rela.text RELA 00000000 000730 0000cc 0c 12 1 4
[ 3] .data PROGBITS 00000000 0000b0 00000c 00 WA 0 0 4
[ 4] .rela.data RELA 00000000 0007fc 000018 0c 12 3 4
[ 5] .bss NOBITS 00000000 0000bc 000000 00 WA 0 0 1
[ 6] .rodata.str1.2 PROGBITS 00000000 0000bc 00008c 01 AMS 0 0 2
[ 7] .modinfo PROGBITS 00000000 000148 00000c 00 A 0 0 2
[ 8] .debug_frame PROGBITS 00000000 000154 0000b0 00 0 0 4
[ 9] .rela.debug_frame RELA 00000000 000814 000030 0c 12 8 4
[10] .comment PROGBITS 00000000 000204 000021 01 MS 0 0 1
[11] .shstrtab STRTAB 00000000 000225 000069 00 0 0 1
[12] .symtab SYMTAB 00000000 0004c0 0001b0 10 13 24 4
[13] .strtab STRTAB 00000000 000670 0000c0 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
There are no program headers in this file.
Relocation section '.rela.text' at offset 0x730 contains 17 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000002 00000c13 R_CR16_IMM32 00000008 .LC3 + 0
0000000a 00001819 R_CR16_DISP24a 00000000 _printk + 0
00000010 00000d13 R_CR16_IMM32 00000002 .LC1 + 0
00000016 0000070d R_CR16_ABS24 00000000 _rwsem + 0
0000001c 00000713 R_CR16_IMM32 00000000 _rwsem + 0
00000028 00000e13 R_CR16_IMM32 0000002e .LC4 + 0
00000030 00001819 R_CR16_DISP24a 00000000 _printk + 0
00000034 0000070d R_CR16_ABS24 00000000 _rwsem + 0
0000003c 0000070d R_CR16_ABS24 00000000 _rwsem + 0
00000044 00000713 R_CR16_IMM32 00000000 _rwsem + 0
0000004c 00000f13 R_CR16_IMM32 0000004c .LC5 + 0
00000054 00001819 R_CR16_DISP24a 00000000 _printk + 0
00000060 00001013 R_CR16_IMM32 00000000 .LC0 + 0
0000006a 00001113 R_CR16_IMM32 00000066 .LC6 + 0
00000072 00001819 R_CR16_DISP24a 00000000 _printk + 0
00000024 00001216 R_CR16_DISP8 00000060 .L5 + 0
00000066 00001316 R_CR16_DISP8 00000026 .L2 + 0
Relocation section '.rela.data' at offset 0x7fc contains 2 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000004 00000703 R_CR16_NUM32 00000000 _rwsem + 4
00000008 00000703 R_CR16_NUM32 00000000 _rwsem + 4
Relocation section '.rela.debug_frame' at offset 0x814 contains 4 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000014 00001403 R_CR16_NUM32 00000000 .Lframe0 + 0
00000018 00001503 R_CR16_NUM32 00000000 .LFB471 + 0
00000084 00001403 R_CR16_NUM32 00000000 .Lframe0 + 0
00000088 00001603 R_CR16_NUM32 00000068 .LFB472 + 0
There are no unwind sections in this file.
Symbol table '.symtab' contains 27 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS sc1445x_dhrystone.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 5
5: 00000000 0 SECTION LOCAL DEFAULT 6
6: 00000000 104 FUNC LOCAL DEFAULT 1 _sc1445x_dhrystone_init
7: 00000000 12 OBJECT LOCAL DEFAULT 3 _rwsem
8: 00000068 18 FUNC LOCAL DEFAULT 1 _sc1445x_dhrystone_exit
9: 00000000 0 SECTION LOCAL DEFAULT 7
10: 00000000 12 OBJECT LOCAL DEFAULT 7 ___mod_license3
11: 00000000 0 SECTION LOCAL DEFAULT 8
12: 00000008 0 NOTYPE LOCAL DEFAULT 6 .LC3
13: 00000002 0 NOTYPE LOCAL DEFAULT 6 .LC1
14: 0000002e 0 NOTYPE LOCAL DEFAULT 6 .LC4
15: 0000004c 0 NOTYPE LOCAL DEFAULT 6 .LC5
16: 00000000 0 NOTYPE LOCAL DEFAULT 6 .LC0
17: 00000066 0 NOTYPE LOCAL DEFAULT 6 .LC6
18: 00000060 0 NOTYPE LOCAL DEFAULT 1 .L5
19: 00000026 0 NOTYPE LOCAL DEFAULT 1 .L2
20: 00000000 0 NOTYPE LOCAL DEFAULT 8 .Lframe0
21: 00000000 0 NOTYPE LOCAL DEFAULT 1 .LFB471
22: 00000068 0 NOTYPE LOCAL DEFAULT 1 .LFB472
23: 00000000 0 SECTION LOCAL DEFAULT 10
24: 00000000 0 NOTYPE GLOBAL DEFAULT UND _printk
25: 00000000 104 FUNC GLOBAL DEFAULT 1 _init_module
26: 00000068 18 FUNC GLOBAL DEFAULT 1 _cleanup_module
No version information found in this file.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [CR16] Problem with TC_LINKRELAX_FIXUP
2012-06-28 12:20 [CR16] Problem with TC_LINKRELAX_FIXUP Jayant R. Sonar
@ 2012-06-30 2:25 ` Alan Modra
2012-07-04 4:28 ` Jayant R. Sonar
0 siblings, 1 reply; 6+ messages in thread
From: Alan Modra @ 2012-06-30 2:25 UTC (permalink / raw)
To: Jayant R. Sonar; +Cc: binutils, mr.swami.reddy
On Thu, Jun 28, 2012 at 12:16:08PM +0000, Jayant R. Sonar wrote:
> Addend in case of non-working configuration is found to be zero where
> as it is 4 in working configuration.
>
> At following URL, I found a change in TC_LINKRELAX_FIXUP was made to
> resolve non-code section fixups at assembly time:
> http://sourceware.org/ml/binutils/2009-07/msg00035.html
>
> If I revert this change, my problem gets solved. But then I start
> getting same problem that Swami had reported earlier in the URL:
> >> libstdc++.a(future.o)(.eh_frame); no .eh_frame_hdr table will be created.
The symptoms you describe say to me that the cr16 md_apply_fix and/or
tc_gen_reloc are broken. On looking, I see fx_offset is set to zero
in md_apply_fix. This would explain why the reloc addend is zeroed.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [CR16] Problem with TC_LINKRELAX_FIXUP
2012-06-30 2:25 ` Alan Modra
@ 2012-07-04 4:28 ` Jayant R. Sonar
2012-07-04 9:40 ` Alan Modra
0 siblings, 1 reply; 6+ messages in thread
From: Jayant R. Sonar @ 2012-07-04 4:28 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils, mr.swami.reddy
Hello Alan,
Thank you for your valuable inputs.
In md_apply_fix(), I removed fixP->fx_offset = 0 and it fixed the
'addend' problem.
However, this change introduced another problem.
My uClinux kernel now crashes while booting the hardware.
I tried retaining this assignment statement under one or more case
statements of "switch (fixP->fx_r_type)", in same function.
However, wherever it solved 'addend' problem it caused kernel crash.
I tried to look into the readelf dump of kernel images. However, apart
from few changes in sizes and addresses there weren't much differences.
Please guide how should I proceed.
Thanks and Regards,
Jayant Sonar
[KPIT Cummins, Pune]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [CR16] Problem with TC_LINKRELAX_FIXUP
2012-07-04 4:28 ` Jayant R. Sonar
@ 2012-07-04 9:40 ` Alan Modra
2012-07-10 3:53 ` Jayant R. Sonar
0 siblings, 1 reply; 6+ messages in thread
From: Alan Modra @ 2012-07-04 9:40 UTC (permalink / raw)
To: Jayant R. Sonar; +Cc: binutils, mr.swami.reddy
On Wed, Jul 04, 2012 at 04:27:28AM +0000, Jayant R. Sonar wrote:
> Please guide how should I proceed.
You should first find a copy of the cr16 ABI, read and understand how
the cr16 relocations are supposed to work.
Next you need to understand the gas concept of fixups. These are
expressions that gas could not resolve at the time an instruction or
directive was parsed, typically generated by fix_new_exp. See struct
fix. Some fixups can be resolved later, for instance if you wrote
.word table_end - table
table:
.byte ..
...
.byte ..
table_end:
At the time the first word holding the table size was parsed, gas
would need to emit a fixup since it doesn't know values for the
symbols in the expression. Later, at any time after gas has parsed
the table_end label, it would be possible to evaluate the fixup to an
absolute value, and write that value. md_apply_fix is the usual place
where this evaluation is applied, and the fixup is marked done. For
those that can't be applied, tc_gen_reloc is responsible for
generating a relocation.
However, targets like cr16 that set linkrelax bypass the call to
md_apply_fix at least for fixups in some sections. That means
tc_gen_reloc now has the job of resolving some fixups as well as
generating relocations, but if you look at the cr16 tc_gen_reloc I see
no support for resolving fixups and writing their values. Not
resolving fixups in tc_gen_reloc might even be correct, but I see a
comment about "no relocation needed" and no code to write out the
value! That can't work unless the value is written out earlier and I
see no evidence of that happening. So your first job is to correct
tc_gen_reloc.
Next you need to rewrite md_apply_fix. I can't give you anything but
general details since I'm not familiar with the cr16 ABI or cr16 code
in general. Nor am I particularly interested in learning about cr16.
As I said earlier, md_apply_fix should resolve and apply some fixups,
setting fx_done for those it applies. It should leave the fixup alone
in other cases, except where some change is needed in reloc type or,
in special cases, where some adjustment in addend is needed. Please
take up any future discussions with Swami.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [CR16] Problem with TC_LINKRELAX_FIXUP
2012-07-04 9:40 ` Alan Modra
@ 2012-07-10 3:53 ` Jayant R. Sonar
0 siblings, 0 replies; 6+ messages in thread
From: Jayant R. Sonar @ 2012-07-10 3:53 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils, mr.swami.reddy
Hello Alan,
Thank you for such a detailed explanation of fixups.
I don't have much knowledge about relocations and their handling.
However, I will refer md_apply_fix and tc_gen_reloc functions of other
ports and try tweaking CR16 port accordingly.
Thanks and Regards,
Jayant Sonar,
[KPIT Cummins, Pune]
^ permalink raw reply [flat|nested] 6+ messages in thread
* [CR16] Problem with TC_LINKRELAX_FIXUP
@ 2012-06-28 12:08 Jayant R. Sonar
0 siblings, 0 replies; 6+ messages in thread
From: Jayant R. Sonar @ 2012-06-28 12:08 UTC (permalink / raw)
To: binutils; +Cc: mr.swami.reddy, amodra, amodra
[-- Attachment #1: Type: text/plain, Size: 2600 bytes --]
Hello,
On CR16 platform I am using Dhrystone application with uClinux kernel.
If I configure it as built-in driver it works fine. However, if in
configure it as loadable module, I get an unexpected behavior.
-----------------------------------------------------------------------
WORKING: Built-in driver output:
[ 0.570000] Starting SC1445x Dhrystone 'driver'
[ 0.580000] rwsem->wait_list is empty
[ 0.580000] head=0015e544 next=0015e544 prev=0015e544
FAILURE: Loadable module output:
[ 13.960000] Starting SC1445x Dhrystone 'driver'
[ 13.960000] rwsem->wait_list is NOT empty
[ 13.970000] head=00fd50bc next=00fd50b8 prev=00fd50b8
-----------------------------------------------------------------------
Problem:
As shown in above dump, Wait_list is supposed to be empty and addresses
of 'next' and 'prev' are expected to be same as 'head'. But in loadable
module, they are lesser than 'head' by 4.
I compared the readelf dumps of object files of these 2 configurations
(Dumps can be found attached with this mail).
I found following differences:
-----------------------------------------------------------------------
WORKING: Built-in driver output:
Relocation section '.rela.data' at offset 0x7fc contains 2 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000004 00000703 R_CR16_NUM32 00000000 _rwsem + 4
00000008 00000703 R_CR16_NUM32 00000000 _rwsem + 4
=================
FAILURE: Loadable module output:
Relocation section '.rela.data' at offset 0x7b8 contains 2 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00000004 00000703 R_CR16_NUM32 00000000 _rwsem + 0
00000008 00000703 R_CR16_NUM32 00000000 _rwsem + 0
----------------------------------------------==================-------
Addend in case of non-working configuration is found to be zero where
as it is 4 in working configuration.
At following URL, I found a change in TC_LINKRELAX_FIXUP was made to
resolve non-code section fixups at assembly time:
http://sourceware.org/ml/binutils/2009-07/msg00035.html
If I revert this change, my problem gets solved. But then I start
getting same problem that Swami had reported earlier in the URL:
>> libstdc++.a(future.o)(.eh_frame); no .eh_frame_hdr table will be created.
(REF: http://sourceware.org/ml/binutils/2009-06/msg00463.html)
Can someone help me finding any other way by which this can be fixed?
Regards,
Jayant Sonar
[KPIT Cummins, Pune]
[-- Attachment #2: failure.txt --]
[-- Type: text/plain, Size: 217 bytes --]
FILE QUARANTINED
Microsoft Forefront Protection for Exchange Server HC02 removed a file since it was found to match a filter.
File name: "winmail.dat->failure.dmp"
Filter name: "FILE FILTER= Custom Filter: *.dmp"
[-- Attachment #3: working.txt --]
[-- Type: text/plain, Size: 217 bytes --]
FILE QUARANTINED
Microsoft Forefront Protection for Exchange Server HC02 removed a file since it was found to match a filter.
File name: "winmail.dat->working.dmp"
Filter name: "FILE FILTER= Custom Filter: *.dmp"
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-07-10 3:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-28 12:20 [CR16] Problem with TC_LINKRELAX_FIXUP Jayant R. Sonar
2012-06-30 2:25 ` Alan Modra
2012-07-04 4:28 ` Jayant R. Sonar
2012-07-04 9:40 ` Alan Modra
2012-07-10 3:53 ` Jayant R. Sonar
-- strict thread matches above, loose matches on Subject: below --
2012-06-28 12:08 Jayant R. Sonar
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).