[Bug binutils/30143] All PE sections are paged

[pali at kernel dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30143

--- Comment #2 from Pali Rohár <pali at kernel dot org> ---
Hello! I'm replying below as inline comments.

(In reply to Nick Clifton from comment #1)
> Hi Pali,
> 
>   OK, so I am assuming that the desired behaviour is specific to the NT
> kernel.
>   Ie, the default of allowing all sections to be paged is correct for most PE
>   binaries, just not the kernel ?

Yes, this issue is about NT kernel drivers. For NT user PE executables is
current behavior correct.

>   Given that, there needs to be some way to distinguish between building a
> kernel 
>   and building a normal binary and the most obvious way is to have a custom 
>   linker script for the kernel.  This script can set the
> IMAGE_SCN_MEM_NOT_PAGED 
>   flag for all sections except one called "PAGE".  Do you agree ?

For sure distinguish between NT kernel driver executables and PE user
executables is needed. And what kind of solution for this is used (custom
linker script, compile switch, ...) I will let to you / binutils developers. I
think that this depends on architecture of the whole project and I do not think
that I see what is the best choice here.

Linker script is being specified by the command line option, so if this new
linker script would be as part of the "standard" PE binutils installation then
for user/developer perspective it is same as the "command line switch" way.

>   So what we need is a way to set PE specific section flags in linker
> scripts.
>   (Which goes against what I said for PR 30145, but I am going through these
>   PRs in reverse order and I now see that there is a genuine need to extend
>   the linker script syntax).

Ok. I know what whole picture is not simple, so I would expect that the final
solution can be changed in time / during development.

>   The linker currently supports setting a section's type via the "TYPE=xxx" 
>   syntax, but that is not quite what we need, since presumably there might
>   be a need to set more than one flag.  So I guess that we need to add a
>   "FLAG=xxx[|xxx]+" syntax.  Then, since the flags are going to be file 
>   format/architecture specific, we need to implement a callback into the
>   linker's emulation framework in order to parse the flags, and another one
>   to set them.  Plus we need to add support for the NOT_PAGED flag to the 
>   BFD library (since it currently does not support it at all).  *sigh* I 
>   was right about this being a big potential source for new bugs.
> 
>   It would be a lot easier to just use objcopy to set the flag after the
>   the link has completed...

In past I have already tried to use objcopy for setting those flags, but
whatever I did was not able. Not sure if there is missing documentation for it,
or it is really not supported (as I created an issue for it). But my current
usage is to compile code, link object files to binary and then post-process
this binary to fix these flags via my custom tool. Replacing my custom tool by
standard objcopy tool is a step forward.

>From "user" perspective, it would be better to allow specifying these flags
directly into linker.

>   Any thoughts ?
> 
> Cheers
>   Nick

Another idea: What about extending GNU AS to allow setting these flags into
COFF object file?

-- 
You are receiving this mail because:
You are on the CC list for the bug.