Bug 25151 - writing section `.text' at huge (ie negative) file offset
Summary: writing section `.text' at huge (ie negative) file offset
Status: RESOLVED WONTFIX
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.33
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-30 17:46 UTC by Alexander Kobets
Modified: 2019-11-04 20:55 UTC (History)
2 users (show)

See Also:
Host: Ubuntu Linux 19.10
Target:
Build:
Last reconfirmed:


Attachments
Object file maked in Ubuntu Linux 19.04 (348 bytes, application/octet-stream)
2019-11-01 10:05 UTC, Alexander Kobets
Details
Object file maked in Ubuntu Linux 19.10 (412 bytes, application/octet-stream)
2019-11-01 10:06 UTC, Alexander Kobets
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kobets 2019-10-30 17:46:34 UTC
Ubuntu Linux 19.10, Kernel 5.3.0
prog.c
======
int start()
{
	return 1;
}
======
gcc -c -mcmodel=kernel -fno-PIC -O2 prog.c
ld  --oformat binary --entry start -Ttext 0xFFFFFFFFFF840000 -o prog.bin prog.o
warning: writing section `.text' at huge (ie negative) file offset
error: File truncated

This error in ld 2.32 too. But this error occur in Ubuntu Linux 19.10. There is no error in Ubuntu Linux 19.04.
Comment 1 Alan Modra 2019-11-01 06:32:01 UTC
Please attach your compiled object file, so that we don't need to guess your compiler version and many other details.  I could not reproduce this bug.
Comment 2 Alexander Kobets 2019-11-01 10:05:37 UTC
Created attachment 12058 [details]
Object file maked in Ubuntu Linux 19.04
Comment 3 Alexander Kobets 2019-11-01 10:06:06 UTC
Created attachment 12059 [details]
Object file maked in Ubuntu Linux 19.10
Comment 4 Alexander Kobets 2019-11-01 10:16:10 UTC
(In reply to Alan Modra from comment #1)
> Please attach your compiled object file, so that we don't need to guess your
> compiler version and many other details.  I could not reproduce this bug.

I am use default packages of gcc and binutils installed by default.
Realy, nor ld version, nor gcc version do not matter. I already probing different versions. Have matter only building platform Ubuntu Linux 19.10 desktop x86_64, that is a problem.
Previous version Ubuntu Linux 19.04 do not have this problem.
Comment 5 Alan Modra 2019-11-02 06:29:52 UTC
There is a .note.gnu.property section in your gcc-9 compiled object file.  This section is an allocated section (and thus will appear in the binary output), and is placed by the generic linker before your .text section at a relatively low address.  Combined with the very high address of your .text section would mean a binary format output file of around 18 exa bytes.  I'm guessing that you don't have such a large storage system.

Use -Ttext-segment=0xff... rather than -Ttext=0xff... when linking if you want the .note.gnu.property section in your output, compile with an option that turns it off, or remove the section before linking.
Comment 6 Alexander Kobets 2019-11-03 09:05:33 UTC
The -Ttext-segment resolve a problem.
Do you know, how to compile with an option, that turns .note.gnu.property section off?
I know, how to use strip, but it clears object so deep, and currently I simple shift 'start' entrypoint around .note.gnu.property section.
Comment 7 Alan Modra 2019-11-04 02:38:51 UTC
(In reply to Alexander Kobets from comment #6)
> Do you know, how to compile with an option, that turns .note.gnu.property
> section off?

Not without spending some time looking.  It is likely to be a -m option.
Comment 8 H.J. Lu 2019-11-04 17:25:09 UTC
(In reply to Alexander Kobets from comment #6)
> The -Ttext-segment resolve a problem.
> Do you know, how to compile with an option, that turns .note.gnu.property
> section off?
> I know, how to use strip, but it clears object so deep, and currently I
> simple shift 'start' entrypoint around .note.gnu.property section.

.note.gnu.property note sections should be discarded in kernel image
via linker script.
Comment 9 Alexander Kobets 2019-11-04 20:55:13 UTC
Ok.