https://sourceware.org/bugzilla/show_bug.cgi?id=28867
--- Comment #8 from Eric Pouech <eric.pouech at orange dot fr> ---
Hi Nick,
I've tried it locally as well, but as you, without much success... ie no error
generated from re-assembling the fail.s file
the exact command line is:
/usr/lib/gcc/i686-w64-mingw32/11.2.1/../../../../i686-w64-mingw32/bin/as -v -I
dlls/dxdiagn -I /home/eric/work/wine-format/dlls/dxdiagn -I include -I
/home/eric/work/wine-format/include -I
/home/eric/work/wine-format/include/msvcrt --gdwarf-4 -o
dlls/dxdiagn/provider.cross.o /tmp/<XXXX>.s
I tried to move around the dev tree (before the dates I opened the bug), but no
modif in the command line
trying to compare the two (the bogus fail.o, and the provider.cross.o) files:
fail.o: file format pe-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000050b0 00000000 00000000 0000021c 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000010 00000000 00000000 000052cc 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000000 2**2
ALLOC
3 .rdata 00001f40 00000000 00000000 000052dc 2**5
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
4 .debug_info 0001f071 00000000 00000000 0000721c 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
5 .debug_abbrev 00000957 00000000 00000000 0002628d 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_loc 00009e70 00000000 00000000 00026be4 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
7 .debug_aranges 00000020 00000000 00000000 00030a54 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
8 .debug_ranges 000022d8 00000000 00000000 00030a74 2**0
CONTENTS, READONLY, DEBUGGING
9 .debug_line 00006a00 00000000 00000000 00032d4c 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
10 .debug_str 00000d9d 00000000 00000000 0003974c 2**0
CONTENTS, READONLY, DEBUGGING
11 .rdata$zzz 00000038 00000000 00000000 0003a4e9 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .eh_frame 00000614 00000000 00000000 0003a521 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
[eric:~/work/wine-format/build32/dlls/dxdiagn]$ LANG=C objdump -h
provider.cross.o
provider.cross.o: file format pe-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000050b0 00000000 00000000 0000021c 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000010 00000000 00000000 000052cc 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000000 2**2
ALLOC
3 .rdata 00001f40 00000000 00000000 000052dc 2**5
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
4 .debug_info 0001f073 00000000 00000000 0000721c 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
5 .debug_abbrev 00000967 00000000 00000000 0002628f 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_loc 00009e70 00000000 00000000 00026bf6 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
7 .debug_aranges 00000020 00000000 00000000 00030a66 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
8 .debug_ranges 000022d8 00000000 00000000 00030a86 2**0
CONTENTS, READONLY, DEBUGGING
9 .debug_line 00006b89 00000000 00000000 00032d5e 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
10 .debug_str 00000d9d 00000000 00000000 000398e7 2**0
CONTENTS, READONLY, DEBUGGING
11 .rdata$zzz 00000038 00000000 00000000 0003a684 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .eh_frame 00000614 00000000 00000000 0003a6bc 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
so what first changes is the .debug_* sections... and looking a bit into them,
objdump -W for the two .o files, and diff -u gives (small excerpt):
@@ -90,7 +90,7 @@
<1fa> DW_AT_name : LPVOID
<201> DW_AT_decl_file : 15
<202> DW_AT_decl_line : 247
- <203> DW_AT_decl_column : 49
+ <203> DW_AT_decl_column : 15
<204> DW_AT_type : <0x208>
<1><208>: Abbrev Number: 128 (DW_TAG_pointer_type)
<20a> DW_AT_byte_size : 4
to summarize the rest of the diff:
- same evolution on most of the DIEs which appear with a modified column
- a couple of DIE:s which require a different abbrev as column cannot be stored
in same dwarf's integer (data1) => which generate the change in size of the
.debug* sections, some DIEs' offset changes...
- I haven't looked further for potentially other differences
just to say I don't grasp where this modification in dwarf's column comes from
(AFAICT fail.s has column information which is consistent with fail.o)
I have no evidence that this variation in the .o files has any relationship
with the failure (or hasn't)... but since we can't grasp anything serious, it
may be worth checking ;-)
maybe, it does ring some bell to you?
A+
--
You are receiving this mail because:
You are on the CC list for the bug.
