[Bug gprofng/29521] [docs] man pages are not in the release tarball

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_40-branch branch has been updated by Vladimir Mezentsev
:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c6e269febbc946a54ed9dbbb2dc70feba6017607

commit c6e269febbc946a54ed9dbbb2dc70feba6017607
Author: Vladimir Mezentsev 
Date:   Fri Jan 20 15:39:55 2023 -0800

gprofng: PR29521 [docs] man pages are not in the release tarball

gprofng/ChangeLog
2023-01-20  Vladimir Mezentsev  

PR gprofng/29521
* configure.ac: Check if $MAKEINFO and $HELP2MAN are missing.
* Makefile.am: Build doc if $MAKEINFO exists.
* doc/gprofng.texi: Update documentation for gprofng.
* doc/Makefile.am: Build gprofng.1.
* src/Makefile.am: Move the build of gprofng.1 to doc/Makefile.am.
* configure: Rebuild.
* Makefile.in: Rebuild.
* doc/Makefile.in: Rebuild.
* src/Makefile.in: Rebuild.

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

[Bug ld/30050] Linker test failures when --as-needed is passed to linker by compiler

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |2.41
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from H.J. Lu  ---
Fixed for 2.41.

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

[Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows

[euloanty at live dot com]

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

--- Comment #13 from cqwrteur  ---
lld does not work for canadian building compiler

Get Outlook for Android

From: nickc at redhat dot com 
Sent: Wednesday, January 25, 2023 8:37:38 AM
To: euloa...@live.com 
Subject: [Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r:
section below image base for windows

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

--- Comment #12 from Nick Clifton  ---
(In reply to cqwrteur from comment #10)

> just any C++ code that would link to libstdc++
>
> #include
>
> int main()
> {
> std::cout<<"Hello World\n";
> }
>
> For example
> remove -s -flto flags they all fail while -fuse-ld=lld would work.

I tried that, but the compilation and link still works for me.  As I said
though, I am using gcc 11 not gcc 13.

(In reply to cqwrteur from comment #11)
> Does the issue come from this patch?
>
> https://github.com/mirror/mingw-w64/commit/
> fc55e181b2d84c8817e3fd9d86c6944ac709acc9

It could do - I am not familiar with the mingw-w64 runtime code, so I cannot
really say.

If you have a workaound - using lld - then I would stick with that for now.

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

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

Issue 52992 in oss-fuzz: binutils:fuzz_objdump: Unexpected-exit in xexit

[sheriffbot via monorail]

Updates:
Labels: Deadline-Approaching

Comment #2 on issue 52992 by sheriffbot: binutils:fuzz_objdump: Unexpected-exit 
in xexit
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=52992#c2

This bug is approaching its deadline for being fixed, and will be automatically 
derestricted within 7 days. If a fix is planned within 2 weeks after the 
deadline has passed, a grace extension can be granted.

- Your friendly Sheriffbot

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.

[Bug ld/30050] Linker test failures when --as-needed is passed to linker by compiler

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by H.J. Lu :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0e46a09d12aa9c2c77d783ace336866e429ffa73

commit 0e46a09d12aa9c2c77d783ace336866e429ffa73
Author: H.J. Lu 
Date:   Wed Jan 25 08:57:57 2023 -0800

i386: Pass -Wl,--no-as-needed to compiler as needed

Pass -Wl,--no-as-needed to linker tests to fix

FAIL: Run pr19031
FAIL: Run got1
FAIL: Undefined weak symbol (-fPIE -no-pie)
FAIL: Undefined weak symbol (-fPIE -pie)

when --as-needed is passed to linker by compiler.

PR ld/30050
* testsuite/ld-i386/i386.exp: Pass -Wl,--no-as-needed to compiler
as needed.

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

[Bug ld/30050] New: Linker test failures when --as-needed is passed to linker by compiler

[hjl.tools at gmail dot com]

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

Bug ID: 30050
   Summary: Linker test failures when --as-needed is passed to
linker by compiler
   Product: binutils
   Version: 2.41 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386-linux

When --as-needed is passed to linker by compiler, I got

FAIL: Run pr19031
FAIL: Run got1
FAIL: Undefined weak symbol (-fPIE -no-pie)
FAIL: Undefined weak symbol (-fPIE -pie)

on i386-linux.

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

[Bug gprofng/29521] [docs] man pages are not in the release tarball

[kurt.goebel at oracle dot com]

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

Kurt Goebel  changed:

   What|Removed |Added

   Priority|P2  |P3

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

[Bug ld/29998] ld terminated with signal 11 [Segmentation fault] under mingw with LTO

[nickc at redhat dot com]

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

--- Comment #22 from Nick Clifton  ---
(In reply to Jan Janssen from comment #21)
Hi Jan,

> I don't mind opening a bug on gcc if you think it's on their side. I would
> not be able to tell.

No.  Thinking about this some more, I am convinced that it must be a linker
problem.  If simply adding --disable-reloc-section to the linker command line
makes everything work, then this indicates that it is ld and not LTO that is to
blame. :-(

I still have no real idea of what is causing the problems however.

I will keep on investigating.  Maybe something will turn up.

Cheers
  Nick

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

[Bug ld/29998] ld terminated with signal 11 [Segmentation fault] under mingw with LTO

[medhefgo at web dot de]

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

--- Comment #21 from Jan Janssen  ---
Of course the reproducer is nonsensical. It's just a minified version of
systemd-boot.

> These files appear to be redundant - their code is never called.

When I minified the code, this appeared to be necessary for the miscompile to
happen. For example, dropping test2.o from the final link will have popcount be
compiled and called correctly.

> Shouldn't this function be called main() rather than run() ?

Since I am trying to build an EFI binary, I cannot use main(). The miscompile
also happens if -Wl,--entry=run is passed when linking.

> If you are linking without the standard libraries, can you really expect
the program to run ?

I don't expect the reproducer to run at all. I only expect it to build
correctly. When building with stdlib+main produces correct output, but that's
not what I need.

So yeah, change the link command to this if you want:
   x86_64-w64-mingw32-gcc -o test.exe -flto -nostdlib -Wl,--entry=run test2.o
test3.o libtest.a -lgcc


> True - but as far as I can see this code will never be called.  So having
LTO eliminate the call to  __popcountdi2 is understandable.

But run does get called (by the EFI runtime). Or for userspace nostdlib stuff:
whichever code loads the stuff is also responsible for calling into the entry
point.

I don't mind opening a bug on gcc if you think it's on their side. I would not
be able to tell.

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

[Bug gprofng/28972] gprofng libraries should be installed under $(pkglibdir)

[matz at suse dot de]

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

Michael Matz  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 CC||matz at suse dot de
 Status|RESOLVED|REOPENED

--- Comment #3 from Michael Matz  ---
This was wrong advise.  The shared _modules_ (the collectors, those which are
loaded by dlopen) should indeed be placed in $(pkglibdir).  But the shared
_library_ libgprofng.so.0 (and its various symlinks) need to stay in $(libdir).

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

[Bug gprofng/30043] libgprofng.so.* are installed to a wrong location

[matz at suse dot de]

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

--- Comment #3 from Michael Matz  ---
Proper shared libraries (those which programs link against via DT_NEEDED) have
to be placed in directories in which the dynamic linker searches for them.  You
can play games with DT_RUNPATH of course but that would not be the normal
action.

So, shared libraries need to be placed in $(libdir).  What you are talking
about are dynamic modules: ELF DSOs intended for dlopen, i.e. to be loaded at
runtime.
Usually the difference is already visual in the filenames: shared libs have
major.minor.micro version files and the foobar.so file is a symlink.  Modules
have just the .so file (and are usually not named 'lib*', though that's a
convention not always followed).

So the DSOs you create for modules (the collector stuff) indeed is properly
placed into $(pkglibdir), but the shared library libgprofng.so.0 (which we know
is one because the gprofng binary links against it) needs to be put into
$(libdir).

I don't know why H.J. suggested to put it into $(pkglibdir) but it's an
incorrect
advise.

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

[Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows

[nickc at redhat dot com]

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

--- Comment #12 from Nick Clifton  ---
(In reply to cqwrteur from comment #10)

> just any C++ code that would link to libstdc++
> 
> #include
> 
> int main()
> {
> std::cout<<"Hello World\n";
> }
> 
> For example
> remove -s -flto flags they all fail while -fuse-ld=lld would work.

I tried that, but the compilation and link still works for me.  As I said
though, I am using gcc 11 not gcc 13.

(In reply to cqwrteur from comment #11)
> Does the issue come from this patch?
> 
> https://github.com/mirror/mingw-w64/commit/
> fc55e181b2d84c8817e3fd9d86c6944ac709acc9

It could do - I am not familiar with the mingw-w64 runtime code, so I cannot
really say.

If you have a workaound - using lld - then I would stick with that for now.

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

[Bug ld/29998] ld terminated with signal 11 [Segmentation fault] under mingw with LTO

[nickc at redhat dot com]

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

--- Comment #20 from Nick Clifton  ---
(In reply to Jan Janssen from comment #18)
Hi Jan,

  There appear to be a few issues with this second test case:

> $ cat test1.c
> void test1() {}
> $ cat test2.c
> void test1(); static void test2() { test1(); }

These files appear to be redundant - their code is never called.

> $ cat test3.c 
> int run(void) {
> volatile unsigned i = 4278190080;
> return __builtin_popcount(i);
> }

Shouldn't this function be called main() rather than run() ?


> $ x86_64-w64-mingw32-gcc -o test.exe -flto -nostdlib test2.o test3.o
> libtest.a -lgcc

If you are linking without the standard libraries, can you really expect
the program to run ?


> When I run the above build steps (with your path applied), they produce the
> same assembly for run(), except for this line:
> 
>14000102b:   e8 00 00 00 00  call   140001030 
> 
> vs this without -flto:
> 
>140001037:   e8 24 00 00 00  call   140001060 <__popcountdi2>
> 
> The lto build doesn't even include popcount and the EFI binary either
> produces a page fault or division error.

True - but as far as I can see this code will never be called.  So having
LTO eliminate the call to  __popcountdi2 is understandable.

At the moment it looks to me like you are trying to do something unusual - ie
creating a binary without the usual start up files or libraries - and this is
not working as expected.  But I am currently unconvinced that the linker is
really to blame for the problems...

Cheers
  Nick

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

[Bug ld/20555] The GNU linker does not generate PDB files

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||nickc at redhat dot com
 Status|NEW |RESOLVED

--- Comment #3 from Nick Clifton  ---
Resolved

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

[Bug ld/29998] ld terminated with signal 11 [Segmentation fault] under mingw with LTO

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
   Last reconfirmed||2023-01-25
 Ever confirmed|0   |1

--- Comment #19 from Nick Clifton  ---
Reopening because the patch has not fixed the underlying problem.

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

[Bug gprofng/30043] libgprofng.so.* are installed to a wrong location

[mliska at suse dot cz]

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

Martin Liska  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Martin Liska  ---
(In reply to Vladimir Mezentsev from comment #1)
> This is not a bug. Not all binutils libraries are installed in $(libdir).
> See, for example, /tmp/install-libdir/bfd-plugins/ in your installation.

Yes, I would expect something similar for gprofng, where 

/tmp/install-libdir/gprofng/libgp-iotrace.so
/tmp/install-libdir/gprofng/libgp-sync.so
/tmp/install-libdir/gprofng/libgp-heap.so
/tmp/install-libdir/gprofng/libgp-collectorAPI.so
/tmp/install-libdir/gprofng/libgp-collector.so

are similar to bfd-plugins, while the main library should be places in
$(libdir):

/tmp/install-libdir/libgprofng.so
/tmp/install-libdir/libgprofng.so.0
/tmp/install-libdir/libgprofng.so.0.0.0

similarly to e.g. libctf.so.0.0.0.

Does it make sense?

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

[Bug ld/29973] x86_64-w64-mingw32-g++ ld: helloworld.exe:.rdata_r: section below image base for windows

[euloanty at live dot com]

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

--- Comment #11 from cqwrteur  ---
Does the issue come from this patch?

https://github.com/mirror/mingw-w64/commit/fc55e181b2d84c8817e3fd9d86c6944ac709acc9

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