[Bug ld/15107] New: Linking against GNU_UNIQUE symbol creates GNU_UNIQUE symbol without selecting GNU ABI

[fweimer at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15107

 Bug #: 15107
   Summary: Linking against GNU_UNIQUE symbol creates GNU_UNIQUE
symbol without selecting GNU ABI
   Product: binutils
   Version: 2.23
Status: NEW
  Severity: minor
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: fwei...@redhat.com
Classification: Unclassified


Created attachment 6848
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6848
unique_shared_ref.s

Instructions (as tested on Fedora 18 x86_64):

$ as unique_shared_ref.s -o unique_shared_ref.o
$ as unique_shared.s -o unique_shared.o
$ ld -shared -o unique_shared_ref.so unique_shared_ref.o
$ ld -o unique_shared_ref  unique_shared_ref.o unique_shared.so
$ readelf -s unique_shared_ref | grep UNIQ
 1:  0 OBJECT  UNIQUE DEFAULT  UND b
11:  0 OBJECT  UNIQUE DEFAULT  UND b
$ readelf -h unique_shared_ref  | grep ABI
  OS/ABI:UNIX - System V
  ABI Version:   0

Either the ABI should be set to GNU, or GNU_UNIQUE shouldn't be used for the
symbol reference.

See this mailing list thread:


-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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

[Bug ld/15107] Linking against GNU_UNIQUE symbol creates GNU_UNIQUE symbol without selecting GNU ABI

[fweimer at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15107

--- Comment #1 from Florian Weimer  2013-02-06 
18:16:25 UTC ---
Created attachment 6849
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6849
unique_shared.s

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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

[Bug ld/15107] Linking against GNU_UNIQUE symbol creates GNU_UNIQUE symbol without selecting GNU ABI

[fweimer at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15107

--- Comment #3 from Florian Weimer  2013-02-06 
19:36:05 UTC ---
(In reply to comment #2)
> Please try this

The reference is now GLOBAL instead of LOOS+0/GNU_UNIQUE.  But I don't know if
this breaks anything else.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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

[Bug gold/15153] gold fails to detect undefined symbol

[fweimer at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15153

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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

[Bug ld/14940] s390 -pie issues with TLS relocations

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug libc/9843] relocation R_386_GOTOFF against undefined hidden symbol '_begin' can not be used when making a shared object

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

  Flags||security-

-- 
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

[Bug ld/17324] ld -r not generate cantunwind records in .ARM.exidx section

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com
  Component|build   |ld
Product|glibc   |binutils
  Flags||security-

--- Comment #2 from Florian Weimer  ---
Reassining to binutils.

-- 
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

[Bug binutils/18879] general protection fault in readelf (byte_get_little_endian(elfcomm.c:149))

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com
  Flags||security-

--- Comment #4 from Florian Weimer  ---
It seems this is just an invalid read.  readelf runs as a separate process, and
the readelf process image only contains the readelf program, system libraries,
and the input file, so I don't think this is a security vulnerability.

-- 
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

[Bug gprof/19904] SIGPROF keeps a large task from ever completing a fork()

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug ld/20515] i686 ifunc and non-default symbol visibility

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com
  Flags||security-

-- 
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

[Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-11-22
 CC||fweimer at redhat dot com
 Ever confirmed|0   |1

--- Comment #2 from Florian Weimer  ---
There is no expectation that strlen can be interposed with the effect that
glibc starts using the interposed version.

Are you concerned about the efficiency loss due to the superfluous load of the
address of the interposed strlen?

-- 
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

[Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr

[fweimer at redhat dot com]

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

--- Comment #6 from Florian Weimer  ---
(In reply to ambrosehua from comment #5)

> But I wonder if glibc defining __GI_strlen is legal for making a strlen
> unavailalble to be interposed in strfry. Is libc.so a special case for symbol
> interposition?

We only make malloc-related symbols available for interposition.  For things
like strlen which are in all standards, it would not make a functional
difference because we could simply say you are not allowed to redefine them. 
But for “open”, which is in POSIX but not ISO C, an application must be able to
define a function called “open” and still call “fopen”, with the behavior
required by ISO C.  If the application definition of “open” was interposed into
glibc, then this would not work.

-- 
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

[Bug ld/12654] R_386_TLS_LDO_32 relocations aren't handled properly with -pie

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug ld/21532] AArch64: Symbol address inconsistency across compilation units

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug ld/16936] $ORIGIN in shared library's rpath not used to find library dependencies at link time

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||fweimer at redhat dot com
 Resolution|--- |DUPLICATE

--- Comment #4 from Florian Weimer  ---
Fixed in binutils 2.28.

*** This bug has been marked as a duplicate of bug 20535 ***

-- 
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

[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||sdvormwa at mtu dot edu

--- Comment #7 from Florian Weimer  ---
*** Bug 16936 has been marked as a duplicate of this bug. ***

-- 
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

[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||fweimer at redhat dot com
 Resolution|--- |FIXED

--- Comment #8 from Florian Weimer  ---
Fixed in binutils 2.28.

-- 
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

[Bug binutils/22136] Support marking "debug" info files with special ET_GNU_DEBUG_* values.

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #1 from Florian Weimer  ---
I think this predominantly affects “strip --only-keep-debug” on the binutils
side, which probably needs another mode of operation.

Note that once we switch to marking separated debuginfo files in this way, we
need to add support for that to all consumers.

-- 
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

[Bug binutils/22136] Support marking "debug" info files with special ET_GNU_DEBUG_* values.

[fweimer at redhat dot com]

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

--- Comment #7 from Florian Weimer  ---
The dynamic linker cannot easily reject to load binaries with a specific
program note because it uses the NOTE program header, and separated debuginfo
currently has invalid program headers (well, the headers themselves are valid,
but they do not refer to data in the executable).  The existing consumers rely
on the fact that the program headers are unchanged from the original program
headers, too.

-- 
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

[Bug binutils/22136] Support marking "debug" info files with special ET_GNU_DEBUG_* values.

[fweimer at redhat dot com]

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

--- Comment #10 from Florian Weimer  ---
(In reply to H.J. Lu from comment #9)
> (In reply to Florian Weimer from comment #7)
> > The dynamic linker cannot easily reject to load binaries with a specific
> > program note because it uses the NOTE program header, and separated
> > debuginfo currently has invalid program headers (well, the headers
> > themselves are valid, but they do not refer to data in the executable).  The
> > existing consumers rely on the fact that the program headers are unchanged
> > from the original program headers, too.
> 
> To support Intel CET, ld.so needs to parse PT_NOTE segment.  Please see
> hjl/cet/property branch:
> 
> https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/hjl/cet/
> property
> 
> I added:
> 
>(_dl_map_object_from_fd): Call DL_PROCESS_PT_NOTE on PT_NOTE
> segment if DL_PROCESS_PT_NOTE is defined.
> 
> +
> +#ifdef DL_PROCESS_PT_NOTE
> +  case PT_NOTE:
> +  DL_PROCESS_PT_NOTE (main_map, ph);
> +  break;
> +#endif
> 
> to do just that.

Your code iterates over the program header.  This is not supported for
seperated debuginfo, as I tried to explain above.  The dynamic linker would
need to use the section headers to locate the note section.

-- 
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

[Bug ld/29235] Some glibc tests crash in DT_RELR relocation on powerpc64le

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

Summary|Some tests crash in |Some glibc tests crash in
   |ELF_DYNAMIC_DO_RELR on  |DT_RELR relocation on
   |powerpc64le |powerpc64le

--- Comment #3 from Florian Weimer  ---
Seen with binutils-2.38-14.fc37.ppc64le, with a 64K page size kernel.
Reassigning to binutils for the time being.

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

[Bug ld/29235] Some tests crash in ELF_DYNAMIC_DO_RELR on powerpc64le

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

  Component|dynamic-link|ld
Product|glibc   |binutils
Version|unspecified |2.38

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

[Bug ld/29235] Some glibc tests crash in DT_RELR relocation on powerpc64le

[fweimer at redhat dot com]

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

--- Comment #4 from Florian Weimer  ---
Created attachment 14139
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14139&action=edit
test-tgmath3-fma reproducer program (XZ-compressed)

The binary crashes glibc-2.35.9000-21.fc37.ppc64le, not just within the glibc
build system.

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

[Bug ld/29235] Some glibc tests crash in DT_RELR relocation on powerpc64le

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Florian Weimer  ---
Right, the commit is missing. I'll request an update from the 2.38 upstream
branch for Fedora rawhide. Sorry for the noise.

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

[Bug ld/29235] Some glibc tests crash in DT_RELR relocation on powerpc64le

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=2095622

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

[Bug gas/29517] DWARF subprograms output by gas-2.39 have a 'void' return type

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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

[Bug ld/29512] ld non-canon ref to canon protected function check breaks Solaris/x86

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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

[Bug ld/14512] -z nodelete should be default for shared libraries

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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

[Bug ld/30824] BFD (GNU Binutils) 2.41 internal error, aborting at elf64-ppc.c:17531 in ppc64_elf_relocate_section

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=2258061
 CC||fweimer at redhat dot com

--- Comment #1 from Florian Weimer  ---
This is likely caused by -Wl,-z,pack-relative-relocs, LTO is a bit of a red
herring.

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

[Bug ld/30824] internal error with -z pack-relative-relocs

[fweimer at redhat dot com]

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

--- Comment #11 from Florian Weimer  ---
I don't think we have seen further problems on ppc64le after Nick has
backported Alan's fix into Fedora rawhide binutils. Thanks.

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

[Bug ld/31868] Provide diagnostic option for ISA marker notes

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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

[Bug binutils/31924] aarch64 kernels built with binutils 2.42.50.20240618 and later fail to boot

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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

[Bug binutils/22444] Incorrect note padding check

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug binutils/22444] Incorrect note padding check

[fweimer at redhat dot com]

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

--- Comment #2 from Florian Weimer  ---
Can we really change this in binutils and glibc at this point?  Don't we have
to change the gabi documentation instead?

-- 
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

[Bug binutils/22875] Strip complains about and then destroys unrecognised relocs

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug ld/22929] x86_64 linker seg-faults when creating a shared object from an input containg relocations against a note section

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug ld/22929] x86_64 linker seg-faults when creating a shared object from an input containg relocations against note section without SHF_ALLOC

[fweimer at redhat dot com]

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

--- Comment #4 from Florian Weimer  ---
(In reply to H.J. Lu from comment #3)
> The value will be wrong.  Linker can only resolve PC relative relocations
> against local definition.

Agreed.  I think we need to fix the producer for these relocations.

-- 
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

[Bug gas/23153] gas: distinct input and output files are not properly detected on not-fully-emulated POSIX platforms

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #8 from Florian Weimer  ---
(In reply to Nick Clifton from comment #5)
> Hi Pekka,
> 
> > No, MinGW populates the st_dev field with some apparently non-random value
> 
> In which case I will go with the original patch.  I know that technically
> a valid file might have an inode of 0, but I think that in practice this
> will never happen since most file systems do not use inode 0, (at least not
> for ordinary files).  Or if they do, it is for a special purpose, such as
> marking that the file has been deleted.

On XFS, inode 0 can be used for regular files created by applications.  Only
newer versions have code in them to avoid inode 0.  Some old applications have
comments that inode 0 indicates a deleted directory entry, but this appears to
be an invention and not something that has ever occurred in practice.

-- 
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

[Bug gas/23153] gas: distinct input and output files are not properly detected on not-fully-emulated POSIX platforms

[fweimer at redhat dot com]

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

--- Comment #10 from Florian Weimer  ---
(In reply to Nick Clifton from comment #9)
> My assumption is that even if inode 0 is valid for the filesystem it is
> extremely unlikely that this value will just happen to be used for an
> assembler input file,
> and extremely unlucky if this file is then used as the output from the
> assembler too.  So basically, it is not worth worrying about.

Agreed.  If this safety check does not kick in because the input and output
files are the same and have inode 0, then this is not a huge problem.

I just wanted to point out that inode number 0 is *not* special on most systems
because that's a common misconception.

-- 
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

[Bug ld/23357] LD debug info cannot be read by valgrind

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug ld/23428] ld does not put program headers in a code-only load segment

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug gold/23535] New: gold needs to produce two PT_NOTE segments with ELFCLASS64

[fweimer at redhat dot com]

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

Bug ID: 23535
   Summary: gold needs to produce two PT_NOTE segments with
ELFCLASS64
   Product: binutils
   Version: 2.31
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: fweimer at redhat dot com
CC: ian at airs dot com
  Target Milestone: ---
 Flags: security-

On ELFCLASS64 targets, the GNU gABI requires 4-byte alignment for
NT_GNU_ABI_TAG and NT_GNU_BUILD_ID, and 8-byte alignment for everything else.

Current gold puts NT_GNU_PROPERTY_TYPE_0 notes into a 4-byte aligned segment,
where they are ignored by the glibc dynamic loader.  This is an
interoperability issue that needs to be address one way or the other.

Further discussion:

https://sourceware.org/ml/binutils/2018-08/msg00292.html

-- 
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

[Bug gas/23840] .symver fails with multiple versions [...] for symbol `...'

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug gold/23455] gold: should the discarded version information warning exist?

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #4 from Florian Weimer  ---
(In reply to Cary Coutant from comment #3)
> It's still really dangerous to discard the version information.

Why is the link editor discarding the symbol version?  Shouldn't it create a
weak symbol with a weak version reference instead?  (Assuming the concern is
the strong version reference.)

-- 
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

[Bug gas/23997] PLT32 relocation is off by 4

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug ld/23937] powerpc64le local ifunc IRELATIVE relocs are wrong

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com
   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1679074

-- 
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

[Bug ld/24458] Linker BFD 2.32 regression: __ehdr_start not useable in shared libraries: "relocation R_X86_64_PC32 against undefined symbol `__ehdr_start' can not be used when making a shared object;

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug gold/17556] crashing when mixing SHF_ALLOC and non SHF_ALLOC sections

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

-- 
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

[Bug ld/24718] Unresolved weak dependency on a versioned symbol should not prevent a program from running

[fweimer at redhat dot com]

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

--- Comment #12 from Florian Weimer  ---
 says this:

  vna_flags
   Bitmask of flags.  Currently the following are defined:

 VER_FLG_WEAK   the reference to this version is weak.

I believe this is what is implemented in glibc, but it's not bean tested so far
because binutils doesn't set this flag.  It should be quite safe to introduce
this feature in binutils (obviously for GNU only).

The Solaris documentation is not helpful at all in this case because our
implementation is so very different.  Based on reading that documentation,
Solaris does not bind individual symbols to versions, only shared object
dependencies as a whole.  Therefore, the problem that weak symbol references
try to solve in Ulrich's approach does not actually arise on Solaris.  Instead,
you can just instruct the link editor to omit certain symbol version references
from the resulting binary, keep a weak (unversioned) symbol reference, and
apply a run-time check, as with any weak symbol.  Since it is not possible to
define multiple symbol versions for the same symbol name on Solaris,
restricting the set of bound symbol versions at static link time is safe.  (In
the GNU implementation, this is unsafe because different versioned symbols can
require different declarations and have different behavior in general, so
deferring this decision to the link editor does not work.)

-- 
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

[Bug ld/24718] BFD ld does not set VER_FLG_WEAK on version reference if all symbols are weak

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

Summary|Unresolved weak dependency  |BFD ld does not set
   |on a versioned symbol   |VER_FLG_WEAK on version
   |should not prevent a|reference if all symbols
   |program from running|are weak

-- 
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

[Bug ld/24718] BFD ld does not set VER_FLG_WEAK on version reference if all symbols are weak

[fweimer at redhat dot com]

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

--- Comment #14 from Florian Weimer  ---
(In reply to Carlos O'Donell from comment #13)
> (In reply to Florian Weimer from comment #12)
> >  says this:
> > 
> >   vna_flags
> >Bitmask of flags.  Currently the following are defined:
> > 
> >  VER_FLG_WEAK   the reference to this version is weak.
> 
> This specification was written and implemented before the glibc community
> corrected their interpretation of the ELF standard and introduced
> LD_DYNAMIC_WEAK to undo similar weak-style changes. That is to say that the
> VER_FLG_WEAK description in "symbol-vresioning" is based on an incorrect
> interpretation of the ELF standard. It was based on the idea that you would
> scan all loaded shared objects for a potentially strong definition that
> overrode the weak one, and you can see this means lazy loading would be
> useless in this case because even one weak symbol means you need to load
> *everything* to confirm no strong symbols override.

Wasn't that disagreement about weak *definitions*?

For weak references, we still have a long-standing ambiguity if the link editor
encounters both weak and non-weak references.

I don't think any of this matters at the versioning level because the version
reference would be weak if all references are weak.  This means that
limitations due to relocation types available for a particular architectures
etc. do not come into play (which impact what you can implement with the actual
symbol bindings).

> > I believe this is what is implemented in glibc, but it's not bean tested so
> > far because binutils doesn't set this flag.  It should be quite safe to
> > introduce this feature in binutils (obviously for GNU only).
> 
> It is because it is a historical implementation. We could deprecate
> LD_DYANMIC_WEAK and remove lots of code and simplify things.

I think it's totally unrelated.  LD_DYANMIC_WEAK only affects weak definitions
in shared objects.  The example does not contain a weak definition.

> > The Solaris documentation is not helpful at all in this case because our
> > implementation is so very different.  Based on reading that documentation,
> > Solaris does not bind individual symbols to versions, only shared object
> > dependencies as a whole. 
> 
> Correct, and if we wanted we could implement the Solaris meaning of
> VER_FLG_WEAK for "weak version definitions." I don't know how we would
> instruct a binding between the binary and the "weak version definition",
> some new linker file construct like Solaris has.

We have the SHT_GNU_verneed section referenced from the dynamic segment.  The
glibc loader processes that, in much the same way as the Solaris loader does
with their data structure.  The key difference is that our link editor puts
only symbol version references there for symbols which are actually referenced
by the link.

Without that, you would be able to run glibc 2.30 binaries only on systems
having glibc 2.30 or later, for example.

> I think the original "symbol-versioning" design simply tried to carry the
> static linker semantics of weak symbol version processing to the dynamic
> linker without consideration for the impact it would have on lazy binding.
> Namely that if you have an undefined weak reference to a symbol, you have to
> search every object looking for a potential strong reference, instead of
> stopping at the first definition (weak or strong) that you find based on
> search order.

You always have to search all objects for an undefined weak symbol.  There is
no defined symbol at which the search can stop.

> > Instead, you can just instruct the link editor to omit certain symbol
> > version references from the resulting binary, keep a weak (unversioned)
> > symbol reference, and apply a run-time check, as with any weak symbol.
> > Since it is not possible to define multiple symbol versions for the same
> > symbol name on Solaris, restricting the set of bound symbol versions at
> > static link time is safe.  (In the GNU implementation, this is unsafe
> > because different versioned symbols can require different declarations and
> > have different behavior in general, so deferring this decision to the link
> > editor does not work.)
> 
> I don't follow what you're trying to state here. Can you expand on this with
> an exmaple please?

Solaris has a capability to specify the symbol versions you want to require
from a specific soname.  See “Specifying a Version Binding” in the
documentation you cited, and in particular “If a shared object has been
versioned over several software releases, application developers can restrict
themselves to the interfaces that were available in a previous software
release. Thus, an application can be built using the latest release of the
shared object in the knowledge that the application's interface requirements
can be met by a previous release of the shared object.”.  Since individual
symbols do not

[Bug ld/24718] BFD ld does not set VER_FLG_WEAK on version reference if all symbols are weak

[fweimer at redhat dot com]

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

--- Comment #16 from Florian Weimer  ---
(In reply to Carlos O'Donell from comment #15)
> I can inject the flag:
> 
> Version definition section '.gnu.version_d' contains 2 entries:
>   Addr: 0x03e8  Offset: 0x0003e8  Link: 4 (.dynstr)
>   00: Rev: 1  Flags: BASE  Index: 1  Cnt: 1  Name: ./foo-run.so
>   0x001c: Rev: 1  Flags: WEAK  Index: 2  Cnt: 1  Name: FOO_1
> 
> And *then* we get the correct WEAK version reference:
> 
> Version needs section '.gnu.version_r' contains 2 entries:
>  Addr: 0x00400428  Offset: 0x000428  Link: 6 (.dynstr)
>   00: Version: 1  File: ./foo-run.so  Cnt: 1
>   0x0010:   Name: FOO_1  Flags: WEAK  Version: 3
>   0x0020: Version: 1  File: libc.so.6  Cnt: 1
>   0x0030:   Name: GLIBC_2.2.5  Flags: none  Version: 2

Really?  That's an odd link editor behavior for our implementation of symbol
versioning.  Shouldn't the WEAK version flag be inherited from the weak
property of the symbol reference.

> but we still fail:
> 
> ./a.out2
> ./a.out2: ./foo-run.so: no version information available (required by
> ./a.out2)
> ./a.out2: relocation error: ./a.out2: symbol foo version FOO_1 not defined
> in file ./foo-run.so with link time reference

I think you botched your patching somehow.  With a WEAK symbol version on the
reference side, I get this:

./a.out2: ./foo-run.so: weak version `FOO_1' not found (required by ./a.out2)
./a.out2: relocation error: ./a.out2: symbol foo version FOO_1 not defined in
file ./foo-run.so with link time reference

Note the changed first message.

The second part is the soname consistency check which causes us a lot of
headache in glibc, e.g. the broken IFUNC-based forwarders in libpthread (bug
20188, bug 19861).

I think we can remove the soname consistency check from the glibc loader
without any ill effect, and then weak version references should work.  Although
we should not print the warning message when we encounter them, I think, like
we don't do this for undefined weak symbols.

-- 
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

[Bug gas/6957] i386 NOPs must be derived from march not mtune

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com
  Flags||security-

-- 
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

[Bug ld/24836] --as-needed leaves unused direct dependencies

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #5 from Florian Weimer  ---
(In reply to crusader.mike from comment #4)
> Is this the reason for this behaviour?
> 
> $ readelf -s procmon.e | grep xalan
>237: 00415bb033 FUNCWEAK   DEFAULT   13
> _ZN11xalanc_1_XalanVe
>289: 00415bb033 FUNCWEAK   DEFAULT   13
> _ZN11xalanc_1_XalanVe
> 
> How can I drill deeper? (i.e. figure out what kind of symbols these are, why
> my executable references them, etc)

Try readelf -sW.  The non-truncated symbol should be decodable by c++filt.

-- 
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

[Bug ld/24721] -Map generates corrupt .note.gnu.property section

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com
   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1736114
  Flags||security-

-- 
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

[Bug ld/24874] New: ld: --gc-sections reorders GNU build attributes

[fweimer at redhat dot com]

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

Bug ID: 24874
   Summary: ld: --gc-sections reorders GNU build attributes
   Product: binutils
   Version: 2.32
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: fweimer at redhat dot com
  Target Milestone: ---

On Fedora rawhide, this reproducer:

cat > t.c <gcc 9.1.1 20190605  0x   OPENApplies to region
from 0
  GA*GOW:0x452a0x   OPENApplies to region
from 0
  GA*off   0x   OPENApplies to region
from 0
  GA+stack_clash:true  0x   OPENApplies to region
from 0
…

The expected order (at least for strip) is like this:

Displaying notes found in: .gnu.build.attributes
  Owner Data size   Description
  GA$3h8770x0010   OPENApplies to region
from 0x401020 to 0x401020 (.annobin_init.c.hot)
  GA$gcc 9.1.1 20190605  0x   OPENApplies to region
from 0x401020
  GA*GOW:0x452a0x   OPENApplies to region
from 0x401020
…

-- 
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

[Bug ld/24920] Executable produces nonsensical error message after statically linking with trying to link in a dynamic library.

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #1 from Florian Weimer  ---
This is caused by the link editor defaulting to /lib/ld64.so.1 as the program
interpreter, which does not existing on x86-64 psABI systems.  Without -static,
the gcc compiler driver overrides that, using -dynamic-linker
/lib64/ld-linux-x86-64.so.2.

Maybe ld should not have a default for the program interpreter at all?

-- 
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

[Bug gas/25295] Gas should have way to define symbol version without exporting its target

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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

[Bug ld/25384] New: Copy relocations and BIND_NOW on POWER ELFv1 results in crashes

[fweimer at redhat dot com]

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

Bug ID: 25384
   Summary: Copy relocations and BIND_NOW on POWER ELFv1 results
in crashes
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: fweimer at redhat dot com
  Target Milestone: ---
Target: powerpc64

Created attachment 12203
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12203&action=edit
libshared.so

This script produces a ./main executable which crashes when run:

cat >like-pthread.c <like-dl.c <shared.c <main.s <https://www.sourceware.org/ml/gnu-gabi/2016-q1/msg4.html>

This crash arises when current glibc is built with --enable-bind-now (see the
downstream report; our 2.17 build includes the --enable-bind-now changes in
glibc master).

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

[Bug ld/25384] Copy relocations and BIND_NOW on POWER ELFv1 results in crashes

[fweimer at redhat dot com]

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

--- Comment #1 from Florian Weimer  ---
Created attachment 12204
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12204&action=edit
liblike-dk.so

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

[Bug ld/25384] Copy relocations and BIND_NOW on POWER ELFv1 results in crashes

[fweimer at redhat dot com]

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

--- Comment #2 from Florian Weimer  ---
Created attachment 12205
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12205&action=edit
liblike-pthread.so

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

[Bug ld/25384] Copy relocations and BIND_NOW on POWER ELFv1 results in crashes

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

  Attachment #12204|liblike-dk.so   |liblike-dl.so
description||

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

[Bug ld/25384] Copy relocations and BIND_NOW on POWER ELFv1 results in crashes

[fweimer at redhat dot com]

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

--- Comment #8 from Florian Weimer  ---
I believe later GCC (I tried 7) uses .data.relro with -O0 and the
__pthread_key_create-based single thread detection, not .rodata. This means
that the current toolchain is consistent and does not produce text relocations.

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

[Bug ld/26065] aarch64: binutils-gdb/ld/testsuite/ld-elf symbolic tests dl4e and dl4f fail

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 Status|WAITING |NEW
Product|glibc   |binutils
  Component|dynamic-link|ld

--- Comment #3 from Florian Weimer  ---
I cannot reproduce this on aarch64:

=== ld Summary ===

# of expected passes245
# of expected failures  2
/root/binutils-gdb/build/ld/ld-new 2.34.50.20200603

The two XFAILs are:

ld/ld.sum:XFAIL: pr22374 function pointer initialization
ld/ld.sum:XFAIL: Run pr19719 fun undefined
ld/ld.log:XFAIL: pr22374 function pointer initialization
ld/ld.log:XFAIL: Run pr19719 fun undefined

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

[Bug ld/26047] Don't allow linking ET_EXEC

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #6 from Florian Weimer  ---
(In reply to Nick Clifton from comment #5)
>   It turns out that there are occasions when linking in executable files
> does make sense, so I am suggesting this patch as a solution.  It provides a
> new linker command line option: -z allowexec  which if used disables all
> warnings about linking in executable files.
> 
>   Comments/questions ?

Could you add some ELF test cases for linking against versioned symbols defined
in the executable? In particular, it's not clear what to record as the soname
in the version records.

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

[Bug ld/26312] New: ld produces broken PLT on aarch64 with BTI+PAC

[fweimer at redhat dot com]

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

Bug ID: 26312
   Summary: ld produces broken PLT on aarch64 with BTI+PAC
   Product: binutils
   Version: 2.35
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: fweimer at redhat dot com
  Target Milestone: ---
Target: aarch64

Building glibc 2.32 on Fedora rawhide with GCC 10.2,
-mbranch-protection=standard, and binutils 2.35 results in a libc.so.6 which
lacks PAC support, possibly due to missing PAC in libgcc.a for the outline
atomics. (We build with -moutline-atomics as well.) This in itself should not
be a problem.

However, catgets/gencat is mislinked.  The PLT is corrupted because its entry
size is not constant (32 bytes for the first entry, 24 bytes for subsequent
entryes, section table says 24 bytes):

Disassembly of section .plt:

00401140 <.plt>:
  401140:   d503245fbti c
  401144:   a9bf7bf0stp x16, x30, [sp, #-16]!
  401148:   d0f0adrpx16, 41f000 <__FRAME_END__+0x1abd4>
  40114c:   f9474a11ldr x17, [x16, #3728]
  401150:   913a4210add x16, x16, #0xe90
  401154:   d61f0220br  x17
  401158:   d503201fnop
  40115c:   d503201fnop

00401160 :
  401160:   d503245fbti c
  401164:   d0f0adrpx16, 41f000 <__FRAME_END__+0x1abd4>
  401168:   f9474e11ldr x17, [x16, #3736]
  40116c:   913a6210add x16, x16, #0xe98
  401170:   d61f0220br  x17
  401174:   d503201fnop

00401178 :
  401178:   d503245fbti c
  40117c:   d0f0adrpx16, 41f000 <__FRAME_END__+0x1abd4>
  401180:   f9475211ldr x17, [x16, #3744]
  401184:   913a8210add x16, x16, #0xea0
  401188:   d61f0220br  x17
  40118c:   d503201fnop

I mentioned the lack of PAC earlier because ld seems to be confused about the
PAC status.  It only sets DT_AARCH64_BTI_PLT:

Dynamic section at offset 0xfc60 contains 29 entries:
  TagType Name/Value
 0x0001 (NEEDED) Shared library: [libc.so.6]
 0x0001 (NEEDED) Shared library:
[ld-linux-aarch64.so.1]
 0x000c (INIT)   0x401120
 0x000d (FINI)   0x403868
 0x0019 (INIT_ARRAY) 0x41fc40
 0x001b (INIT_ARRAYSZ)   8 (bytes)
 0x001a (FINI_ARRAY) 0x41fc48
 0x001c (FINI_ARRAYSZ)   8 (bytes)
 0x0004 (HASH)   0x400330
 0x6ef5 (GNU_HASH)   0x400498
 0x0005 (STRTAB) 0x400990
 0x0006 (SYMTAB) 0x4004e0
 0x000a (STRSZ)  575 (bytes)
 0x000b (SYMENT) 24 (bytes)
 0x0015 (DEBUG)  0x0
 0x0003 (PLTGOT) 0x41fe80
 0x0002 (PLTRELSZ)   1008 (bytes)
 0x0014 (PLTREL) RELA
 0x0017 (JMPREL) 0x400d30
 0x0007 (RELA)   0x400c88
 0x0008 (RELASZ) 168 (bytes)
 0x0009 (RELAENT)24 (bytes)
 0x7001 (AARCH64_BTI_PLT)
 0x0018 (BIND_NOW)   
 0x6ffb (FLAGS_1)Flags: NOW
 0x6ffe (VERNEED)0x400c38
 0x6fff (VERNEEDNUM) 2
 0x6ff0 (VERSYM) 0x400bd0
 0x (NULL)   0x0

But the note says it has both:

Displaying notes found in: .note.gnu.property
  OwnerData sizeDescription
  GNU  0x0010   NT_GNU_PROPERTY_TYPE_0
  Properties: AArch64 feature: BTI, PAC

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

[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #5 from Florian Weimer  ---
There are also PLT patching tools which would benefit from accurate entry
sizes.  (ltrace is an example, I believe.)

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

[Bug ld/15146] Reference from dummy plugin symbol isn't removed

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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

[Bug ld/26314] Linking LTO objects with conflicting symbol definitions from static and shared libraries fails

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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

[Bug gas/23465] wrongly scale non-8-bit x86 displacements

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com
   See Also||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1869401
  Flags||security-

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

[Bug ld/26815] Unnecessary error on linking STV_PROTECTED library: relocation R_X86_64_PC32 against protected symbol `f' can not be used when making a shared object

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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

[Bug gas/27243] --gdwarf-5 doesn't work on nios2

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

Summary|--gdwarf-5 doesn't work |--gdwarf-5 doesn't work on
   ||nios2
 CC|        |fweimer at redhat dot com

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

[Bug gas/27243] --gdwarf-5 doesn't work on nios2

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=97683

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

[Bug binutils/13302] IRELATIVE relocation should come last

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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

[Bug ld/27923] ld: Support DT_RELR relative relocation format

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

  Flags||security-
 CC||fweimer at redhat dot com

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

[Bug gas/28595] glibc-2.34 build fails with linker error (TLS transition from R_386_TLS_GOTIE to R_386_TLS_LE_32 against `__libc_tsd_CTYPE_B' at 0xf4 in section `.text' failed)

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

  Component|build   |gas
Product|glibc   |binutils

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

[Bug gas/28595] glibc-2.34 build fails with linker error (TLS transition from R_386_TLS_GOTIE to R_386_TLS_LE_32 against `__libc_tsd_CTYPE_B' at 0xf4 in section `.text' failed)

[fweimer at redhat dot com]

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

--- Comment #20 from Florian Weimer  ---
I think the relocations can't be placed into arbitrary instructions because the
linker must be able to find the start of the instruction to adjust the
instruction prefix. So GAS really should not assemble this code.

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

[Bug binutils/28689] New: p_align in ELF program headers should not exceed section alignment

[fweimer at redhat dot com]

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

Bug ID: 28689
   Summary: p_align in ELF program headers should not exceed
section alignment
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: fweimer at redhat dot com
  Target Milestone: ---

Currently, on 32-bit and 64-bit Arm, it seems that BFD ld generates p_align
values of 65536 even if no section alignment is greater than 4096. The issue is
more general and probably affects other targets with multiple common page
sizes.

While file layout absolutely must take 64K page size into account, that does
not have to be reflected in the p_align value. If running on a 64K kernel, the
file will be loaded at a 64K page boundary by necessity. On a 4K kernel, 64K
alignment is not needed.

We are going to fix the glibc loader to honor p_align (bug 28676). This means
that on 4K kernels, we will start to do extra work for 64K p_align, but this
pointless for pretty much all binaries (whose section alignment rarely exceeds
16).

A further complication is glibc bug 28688. So I'm not entirely sure anymore
what we should do here.

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

[Bug ld/28743] New: BFD ld: ELF LOAD segments creating holes in the process image on GNU/Linux

[fweimer at redhat dot com]

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

Bug ID: 28743
   Summary: BFD ld: ELF LOAD segments creating holes in the
process image on GNU/Linux
   Product: binutils
   Version: 2.37
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: fweimer at redhat dot com
CC: hjl.tools at gmail dot com
  Target Milestone: ---
 Flags: security-

BFD ld sometimes creates executables that have holes between PT_LOAD segments.

An example is /usr/bin/psql in postgresql-13.4-2.fc35.x86_64 (Fedora 35).

The kernel creates an actual hole, as can be seen from /proc/self/maps:

5591bcaa6000-5591bcab9000 r--p  103:02 271992   
/usr/bin/psql
5591bcab9000-5591bcb0b000 r-xp 00013000 103:02 271992   
/usr/bin/psql
5591bcb0b000-5591bcb49000 r--p 00065000 103:02 271992   
/usr/bin/psql
[49096 byte hole here]
5591bcb4a000-5591bcb52000 r--p 000a3000 103:02 271992   
/usr/bin/psql
5591bcb52000-5591bcb53000 rw-p 000ab000 103:02 271992   
/usr/bin/psql

I assume this position-independent executable was linked with -z separate-code
(our toolchain default). binutils-2.37-10.fc35.x86_64 was used for this build.

This does not happen for all executables. I do not know the triggering
conditions.

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

[Bug ld/28743] BFD ld: ELF LOAD segments creating holes in the process image on GNU/Linux

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=28732

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

[Bug ld/28743] BFD ld: ELF LOAD segments creating holes in the process image on GNU/Linux

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #2 from Florian Weimer  ---
There are 31 section headers, starting at offset 0xad2b8:

Section Headers:
  [Nr] Name  TypeAddress  OffSize   ES Flg
Lk Inf Al
  [ 0]   NULL 00 00 00 
0   0  0
  [ 1] .interp   PROGBITS0318 000318 1c 00   A 
0   0  1
  [ 2] .note.gnu.property NOTE0338 000338 50 00   A
 0   0  8
  [ 3] .note.gnu.build-id NOTE0388 000388 24 00   A
 0   0  4
  [ 4] .note.ABI-tag NOTE03ac 0003ac 20 00   A 
0   0  4
  [ 5] .gnu.hash GNU_HASH03d0 0003d0 b4 00   A 
6   0  8
  [ 6] .dynsym   DYNSYM  0488 000488 001458 18   A 
7   1  8
  [ 7] .dynstr   STRTAB  18e0 0018e0 000af7 00   A 
0   0  1
  [ 8] .gnu.version  VERSYM  23d8 0023d8 0001b2 02   A 
6   0  2
  [ 9] .gnu.version_rVERNEED 2590 002590 c0 00   A 
7   2  8
  [10] .rela.dyn RELA2650 002650 00f150 18   A 
6   0  8
  [11] .rela.plt RELA000117a0 0117a0 001200 18  AI 
6  24  8
  [12] .init PROGBITS00013000 013000 1b 00  AX 
0   0  4
  [13] .plt  PROGBITS00013020 013020 000c10 10  AX 
0   0 16
  [14] .plt.sec  PROGBITS00013c30 013c30 000c00 10  AX 
0   0 16
  [15] .text PROGBITS00014830 014830 0505e2 00  AX 
0   0 16
  [16] .fini PROGBITS00064e14 064e14 0d 00  AX 
0   0  4
  [17] .rodata   PROGBITS00065000 065000 032dc0 00   A 
0   0 32
  [18] .eh_frame_hdr PROGBITS00097dc0 097dc0 000dc4 00   A 
0   0  4
  [19] .eh_frame PROGBITS00098b88 098b88 009ca8 00   A 
0   0  8
  [20] .init_array   INIT_ARRAY  000a4130 0a3130 08 08  WA 
0   0  8
  [21] .fini_array   FINI_ARRAY  000a4138 0a3138 08 08  WA 
0   0  8
  [22] .data.rel.ro  PROGBITS000a4140 0a3140 007658 00  WA 
0   0 32
  [23] .dynamic  DYNAMIC 000ab798 0aa798 000220 10  WA 
7   0  8
  [24] .got  PROGBITS000ab9b8 0aa9b8 000640 08  WA 
0   0  8
  [25] .data PROGBITS000ac000 0ab000 0004e0 00  WA 
0   0 32
  [26] .bss  NOBITS  000ac4e0 0ab4e0 000858 00  WA 
0   0 32
  [27] .gnu.build.attributes NOTE000aed38 0ab4e0 000438 00 
0   0  4
  [28] .gnu_debuglinkPROGBITS 0ab918 24 00 
0   0  4
  [29] .gnu_debugdataPROGBITS 0ab93c 001838 00 
0   0  1
  [30] .shstrtab STRTAB   0ad174 00013e 00 
0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), l (large), p (processor specific)

Elf file type is DYN (Position-Independent Executable file)
Entry point 0x15f50
There are 13 program headers, starting at offset 64

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz
  Flg Align
  PHDR   0x40 0x0040 0x0040 0x0002d8
0x0002d8 R   0x8
  INTERP 0x000318 0x0318 0x0318 0x1c
0x1c R   0x1
  [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD   0x00 0x 0x 0x0129a0
0x0129a0 R   0x1000
  LOAD   0x013000 0x00013000 0x00013000 0x051e21
0x051e21 R E 0x1000
  LOAD   0x065000 0x00065000 0x00065000 0x03d830
0x03d830 R   0x1000
  LOAD   0x0a3130 0x000a4130 0x000a4130 0x0083b0
0x008c08 RW  0x1000
  DYNAMIC0x0aa798 0x000ab798 0x000ab798 0x000220
0x000220 RW  0x8
  NOTE   0x000338 0x0338 0x0338 0x50
0x50 R   0x8
  NOTE   0x000388 0x0388 0x0388 0x44
0x44 R   0x4
  GNU_PROPERTY   0x000338 0x0338 0x0338 0x50
0x50 R   0x8
  GNU_EH_FRAME   0x097dc0 0x00097dc0 0x00097dc0 0x000dc4
0x000dc4 R   0x4
  GNU_STACK  0x00 0x 0x 0x00
0x00 RW  0x10
  GNU_RELRO  0x0a3130 0x000a4130 0x000a4130

[Bug ld/28743] BFD ld: ELF LOAD segments creating holes in the process image on GNU/Linux

[fweimer at redhat dot com]

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

--- Comment #4 from Florian Weimer  ---
Could this be the result of running dwz on the binary? Thanks.

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

[Bug ld/28743] BFD ld: ELF LOAD segments creating holes in the process image on GNU/Linux

[fweimer at redhat dot com]

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

--- Comment #7 from Florian Weimer  ---
(In reply to H.J. Lu from comment #6)
> Can elf/tst-dl_find_object in glibc test be used as a testcase?

I don't think so. The failure you saw has a different cause: we do not
initialize l_contiguous for the main map at all. My elf/tst-dl_find_object
binary is actually contiguous.

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

[Bug ld/28743] BFD ld: ELF LOAD segments creating holes in the process image on GNU/Linux

[fweimer at redhat dot com]

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

--- Comment #9 from Florian Weimer  ---
Created attachment 13890
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13890&action=edit
ehframeopt.tar.gz

A reproducer.

$ ./ehframeopt  | head -n 5
0040-00401000 r--p  00:25 506445
/tmp/ehframeopt/ehframeopt
00401000-00407000 r-xp 1000 00:25 506445
/tmp/ehframeopt/ehframeopt
00407000-0040f000 r--p 7000 00:25 506445
/tmp/ehframeopt/ehframeopt
0041-00411000 r--p f000 00:25 506445
/tmp/ehframeopt/ehframeopt
00411000-00412000 rw-p 0001 00:25 506445
/tmp/ehframeopt/ehframeopt

Gap is before the 0041 line.  The reproducer is a bit fickle, the gap
doesn't grow larger merely by increasing the number of object files.

Note that I called this ehframeopt, but I don't know of that's the culprit.
Jakub points towards bug 23704.

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

[Bug ld/2655] Incorrrect padding for .eh_frame section

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

  Flags||security-
 CC||fweimer at redhat dot com

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

[Bug ld/28814] New: Support creating empty ELF symbol versions without VER_FLG_WEAK

[fweimer at redhat dot com]

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

Bug ID: 28814
   Summary: Support creating empty ELF symbol versions without
VER_FLG_WEAK
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: fweimer at redhat dot com
CC: hjl.tools at gmail dot com
  Target Milestone: ---

In some sense this is opposite of bug 24718.

If an object defines a sequence of versions A, B, C, and does not associate any
symbol versions with (say) version B, BFD ld sets VER_FLG_WEAK on that symbol
version. It would be nice if this could be avoided. In glibc, to suppress the
flag, we currently create an otherwise-unused placeholder symbol. If we had a
way to avoid the flag, we would not need to do that.

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

[Bug ld/24718] BFD ld does not set VER_FLG_WEAK on version reference if all symbols are weak

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=28814

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

[Bug ld/28814] Support creating empty ELF symbol versions without VER_FLG_WEAK

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #2 from Florian Weimer  ---
Version definition section '.gnu.version_d' contains 4 entries:
 Addr: 0x04a8  Offset: 0x0004a8  Link: 5 (.dynstr)
  00: Rev: 1  Flags: BASE  Index: 1  Cnt: 1  Name: a.out
  0x001c: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: VER_1
  0x0038: Rev: 1  Flags: WEAK  Index: 3  Cnt: 2  Name: VER_2
  0x0054: Parent 1: VER_1
  0x005c: Rev: 1  Flags: none  Index: 4  Cnt: 2  Name: VER_3
  0x0078: Parent 1: VER_2

a.out built from:

$ head -v ex.c ex.lds 
==> ex.c <==
void f1(void) {}
void f3(void) {}

==> ex.lds <==
VER_1 {
  global: f1;
  local: *;
};
VER_2 {
} VER_1;
VER_3 {
  global: f2;
} VER_2;

using:

gcc -shared ex.c -Wl,--version-script=ex.lds

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

[Bug ld/28814] Support creating empty ELF symbol versions without VER_FLG_WEAK

[fweimer at redhat dot com]

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

--- Comment #3 from Florian Weimer  ---
Mailing list thread:

[PATCH] elf: Don't set VER_FLG_WEAK
https://sourceware.org/pipermail/binutils/2022-January/119497.html

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

[Bug ld/28743] -z relro creats holes in the process image on GNU/Linux

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=31943

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

[Bug ld/32671] Default to erroring out on executable stacks

[fweimer at redhat dot com]

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

--- Comment #2 from Florian Weimer  ---
Maybe error only if the lack of executable stack markup is due to the lack of
markup in any of the inputs, as opposed to an explicit request for an
executable stack?

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

[Bug ld/32572] -z force-bti + -Ttext-segment produce wrong PLT entries on aarch64

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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

[Bug ld/24600] Support --start-lib --end-lib

[fweimer at redhat dot com]

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

--- Comment #3 from Florian Weimer  ---
With .a archives, BFD ld binds symbol references to the same archive even if
they are available from other archives earlier on the command line. Should this
behavior apply to --start-lib/--end-lib as well?

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

[Bug ld/24600] Support --start-lib --end-lib

[fweimer at redhat dot com]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

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