https://sourceware.org/bugzilla/show_bug.cgi?id=21459
--- Comment #4 from Egon Elbre <egonelbre at gmail dot com> ---
(In reply to Nick Clifton from comment #3)
> Created attachment 10044 [details]
> Linker script fragment
>
> Hi Egon,
>
> > But, it does look like it's using new linker and doesn't create a valid
> > executable. Will investigate further.
>
> Darn! I assume that the problem is still the same - ie the
> .debug_gdb_scripts section is still being placed at VMA 0 ?
I've confirmed that it reaches `place = &hold[orphan_debug]` and it uses new
`ld`.
VMA is not zero... it's 1 << 32.
Using section `.debug_gdb_scripts`
$ objdump -h a.exe
a.exe: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .debug_gdb_scripts 00000010 0000000100000000 0000000100000000 00000480
2**3
CONTENTS, READONLY, DEBUGGING
1 .debug_abbrev 00002507 0000000100001000 0000000100001000 00000680 2**0
CONTENTS, READONLY, DEBUGGING
2 .debug_line 00002b24 0000000100004000 0000000100004000 00002c80 2**0
CONTENTS, READONLY, DEBUGGING
3 .debug_frame 00000a00 0000000100007000 0000000100007000 00005880 2**3
CONTENTS, READONLY, DEBUGGING
4 .debug_str 000007c6 0000000100008000 0000000100008000 00006280 2**0
CONTENTS, READONLY, DEBUGGING
5 .debug_loc 00002bb4 0000000100009000 0000000100009000 00006a80 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_ranges 00000560 000000010000c000 000000010000c000 00009680 2**0
CONTENTS, READONLY, DEBUGGING
7 .text 00001da8 0000000000401000 0000000000401000 00009e00 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
8 .data 000000a8 0000000000403000 0000000000403000 0000bc00 2**4
CONTENTS, ALLOC, LOAD, DATA
9 .rdata 000009a0 0000000000404000 0000000000404000 0000be00 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .pdata 00000264 0000000000405000 0000000000405000 0000c800 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .xdata 00000208 0000000000406000 0000000000406000 0000cc00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .bss 00000990 0000000000407000 0000000000407000 00000000 2**5
ALLOC
13 .idata 000007f8 0000000000408000 0000000000408000 0000d000 2**2
CONTENTS, ALLOC, LOAD, DATA
14 .CRT 00000068 0000000000409000 0000000000409000 0000d800 2**3
CONTENTS, ALLOC, LOAD, DATA
15 .tls 00000068 000000000040a000 000000000040a000 0000da00 2**5
CONTENTS, ALLOC, LOAD, DATA
16 .rsrc 000004e8 000000000040b000 000000000040b000 0000dc00 2**2
CONTENTS, ALLOC, LOAD, DATA
17 .debug_aranges 000003d0 000000000040c000 000000000040c000 0000e200 2**0
CONTENTS, READONLY, DEBUGGING
18 .debug_info 00048ae3 000000000040d000 000000000040d000 0000e600 2**0
CONTENTS, READONLY, DEBUGGING
When using section `.xxxxx_gdb_scripts` the executable works and gives this
result (maybe this helps):
a.exe: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00001da8 0000000000401000 0000000000401000 00000600 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 000000a8 0000000000403000 0000000000403000 00002400 2**4
CONTENTS, ALLOC, LOAD, DATA
2 .xxxxx_gdb_scripts 00000010 0000000000404000 0000000000404000 00002600
2**3
CONTENTS, ALLOC, LOAD, DATA
3 .rdata 000009a0 0000000000405000 0000000000405000 00002800 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .pdata 00000264 0000000000406000 0000000000406000 00003200 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .xdata 00000208 0000000000407000 0000000000407000 00003600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .bss 00000990 0000000000408000 0000000000408000 00000000 2**5
ALLOC
7 .idata 000007f8 0000000000409000 0000000000409000 00003a00 2**2
CONTENTS, ALLOC, LOAD, DATA
8 .CRT 00000068 000000000040a000 000000000040a000 00004200 2**3
CONTENTS, ALLOC, LOAD, DATA
9 .tls 00000068 000000000040b000 000000000040b000 00004400 2**5
CONTENTS, ALLOC, LOAD, DATA
10 .rsrc 000004e8 000000000040c000 000000000040c000 00004600 2**2
CONTENTS, ALLOC, LOAD, DATA
11 .debug_aranges 000003d0 000000000040d000 000000000040d000 00004c00 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_info 00048ae3 000000000040e000 000000000040e000 00005000 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_abbrev 00002507 0000000000457000 0000000000457000 0004dc00 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_line 00002b24 000000000045a000 000000000045a000 00050200 2**0
CONTENTS, READONLY, DEBUGGING
15 .debug_frame 00000a00 000000000045d000 000000000045d000 00052e00 2**3
CONTENTS, READONLY, DEBUGGING
16 .debug_str 000007c6 000000000045e000 000000000045e000 00053800 2**0
CONTENTS, READONLY, DEBUGGING
17 .debug_loc 00002bb4 000000000045f000 000000000045f000 00054000 2**0
CONTENTS, READONLY, DEBUGGING
18 .debug_ranges 00000560 0000000000462000 0000000000462000 00056c00 2**0
CONTENTS, READONLY, DEBUGGING
>
> > A quick question,
>
> > Is there a workaround to coerce the unfixed ld to behave similarly via
> > command-line flags or some config script?
>
> Actually, yes there is. :-) Have a look at the attached linker script
> fragment.
> It tells the linker exactly where it should place the .debug_gdb_scripts
> section. You can use this fragment to augment the already existing,
> built-in, linker script by using this on your linker command line:
>
> -T debug.ld
>
> or if you are using gcc or g++:
>
> -Wl,-T,debug.ld
>
> Now this fix will only work for the .debug_gdb_scripts section, but you can
> easily edit the debug.ld file and add in other problematic sections as you
> wish.
Awesome!
Thank you very much. I think this should help fix a bug in Go and Rust at
the same time. :D
>
> You may ask, "why not just add these sections to the built-in linker script
> ?". We could - but - that would only solve the problem for those specific
> sections. The patch that I created is intended to work for any .debug_xxx
> section, regardless of its name.
>
> Cheers
> Nick
--
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
