[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows
From: |
egonelbre at gmail dot com |
Subject: |
[Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows |
Date: |
Mon, 15 May 2017 13:42:20 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=21459
--- Comment #11 from Egon Elbre <egonelbre at gmail dot com> ---
(In reply to Nick Clifton from comment #10)
> Hi Egon,
>
> (In reply to Egon Elbre from comment #8)
>
> > I'm wondering whether Wine or ReactOS will fail with that executable?
>
> Maybe - I could also set up a proper MinGW or Cygwin environment. The
> real problem is time - I just do not have enough of it to spend on these
> bugs. :-(
Sure, I understand.
>
> > Do you see the same result with objdump?
>
> Oh yes - I just thought that the non-zero VMA value would be enough. I did
> not know that there was going to be a problem with large gaps between parts
> of the program and/or excessively large VMA values.
>
> > Sure, if it seems too much work it's fine to include in the script.
>
> I have gone ahead and done that. It is a simple, easy fix that will let you
> get on with your work for now.
>
> > Maybe there's a good place to put an ASSERT bomb when it tries to write VMA
> > 0xFFFFFFFFLL or zero?
>
> Probably. Although I would love to know if it is the high VMA address that
> is causing the problem, or the gap between the two parts of the program that
> is causing the problem. (We are talking 64-bit binaries here, right ?)
After testing some more it seems that when you set the VMA=0x0, then objdump
will show it as 0x100000000. I'm not sure whether it's intentional (per spec)
or not (an underflow).
After searching about gap issues in PE, I found these:
https://github.com/msekletar/sbsigntool/blob/a6043253a4f8621b8eac0fd099e26a8a992cb13a/src/image.c#L331
https://stackoverflow.com/questions/32378033/why-does-section-virtual-addresses-need-to-be-continuous
Few links later I found PE/Coff spec, which says:
In an image file, the VAs for sections must be assigned by the
linker so that they are in ascending order and adjacent, and
they must be a multiple of the SectionAlignment value in the
optional header.
and also...
In an image file, the section data must be aligned on a boundary
as specified by the FileAlignment field in the optional header.
Section data must appear in order of the RVA values for the
corresponding sections (as do the individual section headers
in the section table).
And after ensuring that sections are adjacent, executable manages to start.
Cheers
Egon
>
> Anyway, I will leave this PR open, but I am not expecting to be able to give
> it a lot of time unless it becomes a real show-stopper for someone.
>
> Cheers
> Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows, (continued)
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows, nickc at redhat dot com, 2017/05/09
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows, egonelbre at gmail dot com, 2017/05/10
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows, nickc at redhat dot com, 2017/05/10
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows, egonelbre at gmail dot com, 2017/05/10
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows, nickc at redhat dot com, 2017/05/11
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows, egonelbre at gmail dot com, 2017/05/11
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows, nickc at redhat dot com, 2017/05/12
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows, egonelbre at gmail dot com, 2017/05/12
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows, cvs-commit at gcc dot gnu.org, 2017/05/15
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows, nickc at redhat dot com, 2017/05/15
- [Bug ld/21459] Wrong location for .debug_gdb_scripts on Windows,
egonelbre at gmail dot com <=