[Bug ld/14426] New: add --ignore-unresolved-symbol from NetBSD
http://sourceware.org/bugzilla/show_bug.cgi?id=14426
Bug #: 14426
Summary: add --ignore-unresolved-symbol from NetBSD
Product: binutils
Version: 2.23 (HEAD)
URL: http://mail-index.netbsd.org/source-changes/2008/04/03
/msg004439.html
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: bugme...@mailinator.com
Classification: Unclassified
Created attachment 6563
--> http://sourceware.org/bugzilla/attachment.cgi?id=6563
add --ignore-unresolved-symbol
Sometimes it's useful to leave a symbol undefined even if -z defs is used. The
symbol can still be resolved by runtime linker.
Here's an example:
// foo.c
#include
#include
#include
extern char **environ;
void foo(void) {
char *spawn_argv[] = { "/usr/bin/printenv", NULL };
char *spawn_envp[] = { (char *)malloc(strlen(environ[0])), NULL };
strcpy(spawn_envp[0], environ[0]);
posix_spawnp(NULL, spawn_argv[0], NULL, NULL, spawn_argv, spawn_envp);
}
$ gcc47 -shared -Wl,-z,defs -o foo.so foo.c -fPIC
/tmp//cc2QDr9J.o: In function `foo':
foo.c:(.text+0x1e): undefined reference to `environ'
foo.c:(.text+0x47): undefined reference to `environ'
collect2: error: ld returned 1 exit status
$ gcc47 -shared -Wl,-z,defs -o foo.so foo.c -fPIC
-Wl,--ignore-unresolved-symbol,environ
$
--
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 gprofng/30779] gprofng: fails to build with musl-1.2.4 (gprofng/src/Data_window.h:56:3: error: 'off64_t' does not name a type; did you mean 'off_t'?)
https://sourceware.org/bugzilla/show_bug.cgi?id=30779 John Doe changed: What|Removed |Added CC||bugmenot at mailinator dot com --- Comment #4 from John Doe --- > I fixed the compiler errors (open64, fgetpo64 and fsetpos64 are redefined) in > gprofng. This seems to be missing in git upstream. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30889] New: can't compile without large file support
https://sourceware.org/bugzilla/show_bug.cgi?id=30889 Bug ID: 30889 Summary: can't compile without large file support Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: bugmenot at mailinator dot com Target Milestone: --- Created attachment 15128 --> https://sourceware.org/bugzilla/attachment.cgi?id=15128&action=edit only use O_LARGEFILE if defined here's a partial patch similar to what zlib uses; of course for a full support some largefile types like ino64_t should not be used directly (but still I'd suggest to include this minor patch to have at least the open option similar to zlib) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30893] New: gprofng uses syscall + perf_event (hwcdrv) and ptrace (gpcollect) without any check and doc
https://sourceware.org/bugzilla/show_bug.cgi?id=30893 Bug ID: 30893 Summary: gprofng uses syscall + perf_event (hwcdrv) and ptrace (gpcollect) without any check and doc Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: bugmenot at mailinator dot com Target Milestone: --- gprofng should either have an option to build without syscall + perf_event or an explicit check in configure for the necessary headers. Similar ptrace should also be tested. Note: both are also not mentioned in the dependencies in the README either -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30894] New: bison should be no hard dependency
https://sourceware.org/bugzilla/show_bug.cgi?id=30894 Bug ID: 30894 Summary: bison should be no hard dependency Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: bugmenot at mailinator dot com Target Milestone: --- Created attachment 15132 --> https://sourceware.org/bugzilla/attachment.cgi?id=15132&action=edit ditribute bison generated files When running from a distribution tarball, bison should not be necessary. The attachement adjust the distribution, so that the generated files will be distributed in exactly the version they were tested with, but configure.ac still needs an adjustment to not abort if bison isn't there. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30895] New: gprofng is not relocatable
https://sourceware.org/bugzilla/show_bug.cgi?id=30895 Bug ID: 30895 Summary: gprofng is not relocatable Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: minor Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: bugmenot at mailinator dot com Target Milestone: --- To reproduce on a clean system: ./configure make make install DESTDIR=/tmp cd /tmp/usr/local/bin ./gprofng collect app ls Creating experiment directory test.1.er (Process ID: 4132928) ... configuration error: can not find libgp-collector.so. run aborted LD_LIBRARY_PATH=../lib ./gprofng collect app ls Creating experiment directory test.1.er (Process ID: 4136138) ... configuration error: can not find libgp-collector.so. run aborted Ideally (one or all): * there is an environment variable to override the search path * the shared library is found via the link loader path * the shared library is searched not fixed on compile-time constant LIBDIR but relative to the installed binary (which would make gprofng relocatable) I didn't found an option to run that outside of the configure-time installation path - is there one? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30896] New: gprofng display text: please provide a way (or document how) to include the object name next to the called functions
https://sourceware.org/bugzilla/show_bug.cgi?id=30896 Bug ID: 30896 Summary: gprofng display text: please provide a way (or document how) to include the object name next to the called functions Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: bugmenot at mailinator dot com Target Milestone: --- "gprofng display text -metrics name:e.%totalcpu -functions" shows the metrics for the function names; given the docs I've tried "gprofng display text -metrics name:soname:e.%totalcpu -functions" results in Error: No data recorded to support metric specification: soname the goal was that instead of 0.230 100.00 0.230 100.00 0.120 52.17 0.120 52.17 func1 the output would be 0.230 100.00 0.230 100.00 0.120 52.17 0.120 52.17 func1 (name.so) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30897] New: Support source view for "referenced" source (e.g. bison)
https://sourceware.org/bugzilla/show_bug.cgi?id=30897 Bug ID: 30897 Summary: Support source view for "referenced" source (e.g. bison) Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: bugmenot at mailinator dot com Target Milestone: --- There is an example within gprofng for that. When looking at QLParser we only can show the source file QLParser.tab.cc, but the really interesting file is QLParser.yy. Using "gprof display text -source QLParser.yy" shows Error: No function or file with given name ` QLParser.yy' found Please provide a way to annotate also those sources. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30898] New: consider multi-threading for gprofng display text
https://sourceware.org/bugzilla/show_bug.cgi?id=30898 Bug ID: 30898 Summary: consider multi-threading for gprofng display text Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: gprofng Assignee: vladimir.mezentsev at oracle dot com Reporter: bugmenot at mailinator dot com Target Milestone: --- recording a sample program that uses lots of shared object files (most loaded with dlopen) using "gprofng collect app" is quite fast; doing the "gprofng display html" afterwards was... unexpected. The first process took several minutes and wrote hundreds of MBs (mostly disassembly) to disk /tmp/install/bin/gp-display-text -limit 100 -viewmode machine -compare off -script display.2.html/gp-script /tmp/binutils-2.41/build/test.2.er The second process ran even much longer (actually I've killt it after taking a single complete core for over 2 hours) perl /tmp/install/bin/gp-display-html --whoami=gprofng display html test.2.er Both processes ran on a single core, so the main question here is: is it possible to use multiple cores for those tasks? Also running "gprofng display text -metrics name:soname:e.%totalcpu -disasm func1" (this function showed 5% usage in the "-functions" flavor) took 6 minutes (that's a huge, generated function). Can anything be done about the run time for the "gprofng display" command? Maybe the default for "gprofng display html" should be to NOT include disassembly (this may be a separate issue though)? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30897] Support source view for "referenced" source (e.g. bison)
https://sourceware.org/bugzilla/show_bug.cgi?id=30897
--- Comment #2 from John Doe ---
Please also consider that (depending on the generator) some functions don't
"start" in their "real sources". Actually this is also the case for
QLParser.yy, where yylex is declared at line 42 but actually defined in the
generated C source.
This is also similar for other generators which may translate
orig.def
~~~
MACRO1(a(4),b)
MACRO2(c,d(3))
~~~
to
program.c
~~~
MACRO1_
{
int a;
int b;
#line orig.def 1
a = 4; b = (somefunc(a);
#line program.c 8
assert (a == b);
}
MACRO02_
{
int c;
int d = 3:
#line orig.def 2
c = otherfunc(d);
#line program.c 18
assert (d == -c);
}
~~~
As the program.c file is generated its profiling is only minor interesting, but
it will be very good to have orig.def in the profiler (it is visible in GDB and
coredumps, too).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gprofng/30896] gprofng display text: please provide a way (or document how) to include the object name next to the called functions
https://sourceware.org/bugzilla/show_bug.cgi?id=30896 --- Comment #2 from John Doe --- Thank you, I've misread the docs, works as expected. You may consider to add this example to the docs as this would make it totally clear. Feel free to either mark this issue as RESOLVED(INVALID) or change it to NEW or RESOLVED concerning the documentation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30897] Support source view for "referenced" source (e.g. bison)
https://sourceware.org/bugzilla/show_bug.cgi?id=30897 --- Comment #3 from John Doe --- (In reply to Vladimir Mezentsev from comment #1) > It is a bug. > A workaround could be to look at the functions from QLParser.yy. > For example: > > gprofng display text -dis QL::yylex > gprofng display text -source QL::yylex This _kind of_ works but still shows the .tab.cc source, not the .yy one. The point is that some people may are interested "in the whole package" - then they inspect the tab.cc, but most will be only interested in "their code", so looking at the .yy will be more useful. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30898] consider multi-threading for gprofng display text
https://sourceware.org/bugzilla/show_bug.cgi?id=30898 --- Comment #2 from John Doe --- (In reply to Vladimir Mezentsev from comment #1) > Did you try > gprofng display text -func /tmp/binutils-2.41/build/test.2.er > > Is this also slow? Sorry I didn't include that information - yes, I've tried that, and no, it's not slow, it works instantly. > May we get your sample program to recreate the experiment on our machines ? Unfortunately those "bigger" tests were done in a proprietary environment where "perf record" is normally used instead, so I can't share that. Also, I _guess_ that the big disassembly (>400MB) _might_ come from the Oracle client, which doesn't distribute debug information. > > Also running > > "gprofng display text -metrics name:soname:e.%totalcpu -disasm func1" > > (this function showed 5% usage in the "-functions" flavor) took 6 minutes > > (that's a huge, generated function). > > The command is incorrect. It should be: > gprofng display text -name short:soname -metrics e.%totalcpu:name -disasm > func1 You're right about the format, but that doesn't make any difference to the time it takes to use it. Note that when I use the "-source" option instead, I get the result within a few seconds. This seems to be another reason not to include the disassembly in "display html" by default, but only on request. Perhaps "filtered" only for some functions? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/23235] New: make check uses system installed ld, not the one build
https://sourceware.org/bugzilla/show_bug.cgi?id=23235 Bug ID: 23235 Summary: make check uses system installed ld, not the one build Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: bugmenot at mailinator dot com Target Milestone: --- There are nor issues during configure or make but make check has unexpected fails. One of the reasons (found in binutils/binutils.log): The ld binary currently installed on the test machine has no --build-id option: Executing on host: gcc /some/userdir/binutils-2.30/binutils/testsuite/binutils-all/testprog.c -g -Wl,--build-id=0x12345678abcdef01 -g -o tmpdir/testprog(timeout = 300) spawn -ignore SIGHUP gcc /some/userdir/binutils-2.30/binutils/testsuite/binutils-all/testprog.c -g -Wl,--build-id=0x12345678abcdef01 -g -o tmpdir/testprog /usr/lib/gcc/i586-suse-linux/4.1.2/../../../../i586-suse-linux/bin/ld: unrecognized option '--build-id=0x12345678abcdef01' /usr/lib/gcc/i586-suse-linux/4.1.2/../../../../i586-suse-linux/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status compiler exited with status 1 FAIL: build-id-debuglink (build) I'm quite sure that this is a bug. Either: this test *should* use the system ld - in this case the test must be skipped (or be expected to fail) Or: the "ld" binary build before should be used Simon Sobisch -- 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/23237] New: make check for ld fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23237 Bug ID: 23237 Summary: make check for ld fails Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: bugmenot at mailinator dot com Target Milestone: --- # of expected passes1566 # of unexpected failures2 # of expected failures 4 # of unresolved testcases 1 # of untested testcases 1 # of unsupported tests 20 FAIL: Run pr21964-1 FAIL: Run pr21964-2 What useful output can I post here? -- 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/23237] make check for ld fails
https://sourceware.org/bugzilla/show_bug.cgi?id=23237 --- Comment #2 from John Doe --- Created attachment 11072 --> https://sourceware.org/bugzilla/attachment.cgi?id=11072&action=edit ld.log internal test results -- 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/10125] New: Fail to link "chained" shared objects
See this simple example (with the old GNU ld):
$ cat a.c
#include
void hello(void)
{
printf("hello\n");
}
$ cat b.c
void hello(void);
void say_hello(void)
{
hello();
}
$ cat c.c
void say_hello(void);
int main()
{
say_hello();
return 0;
}
$ gcc -fPIC -shared -o liba.so a.c
$ gcc -fPIC -shared -L. -la -o liba.so a.c
$ LD_LIBRARY_PATH=. gcc -lb -L. -o c c.c
$ LD_LIBRARY_PATH=. ./c
hello
Now when using gold, it fails to link the "c" program because it can't find the
reference to 'hello', found in liba.so:
$ gcc -fPIC -shared -o liba.so a.c
$ gcc -fPIC -shared -L. -la -o liba.so a.c
$ LD_LIBRARY_PATH=. gcc -lb -L. -o c c.c
/usr/bin/ld: ./libb.so: undefined reference to 'hello'
collect2: ld returned 1 exit status
Thanks.
--
Summary: Fail to link "chained" shared objects
Product: binutils
Version: 2.19
Status: NEW
Severity: normal
Priority: P2
Component: gold
AssignedTo: ian at airs dot com
ReportedBy: bugmenot at mailinator dot com
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=10125
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10125] Fail to link "chained" shared objects
--- Additional Comments From bugmenot at mailinator dot com 2009-05-04 00:12 --- Never mind, this was a stripped down testcase from a bigger problem which was wrong. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=10125 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10126] New: internal error in relocate_sections, at ../../gold/reloc.cc:737
(pthread_54_1224.o): bad e_ehsize (36 != 52) /usr/bin/ld: /home/luca/tesis/dmd2/linux/bin/../lib/libphobos2.a(aaA.o): bad e_ehsize (36 != 52) /usr/bin/ld: /home/luca/tesis/dmd2/linux/bin/../lib/libphobos2.a(aaA_a_240.o): bad e_ehsize (36 != 52) /usr/bin/ld: /home/luca/tesis/dmd2/linux/bin/../lib/libphobos2.a(stdarg_1a_b6c.o): bad e_ehsize (36 != 52) /usr/bin/ld: /home/luca/tesis/dmd2/linux/bin/../lib/libphobos2.a(stdarg_1b_aeb.o): bad e_ehsize (36 != 52) /usr/bin/ld: internal error in relocate_sections, at ../../gold/reloc.cc:737 collect2: ld returned 1 exit status --- errorlevel 1 [1] http://www.digitalmars.com/d/download.html -- Summary: internal error in relocate_sections, at ../../gold/reloc.cc:737 Product: binutils Version: 2.19 Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: ian at airs dot com ReportedBy: bugmenot at mailinator dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=10126 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10126] internal error in relocate_sections, at ../../gold/reloc.cc:737
--- Additional Comments From bugmenot at mailinator dot com 2009-05-10 04:24 --- Created an attachment (id=3929) --> (http://sourceware.org/bugzilla/attachment.cgi?id=3929&action=view) Object file example Here is an example object. I'm pretty sure the compiler generates the binary. The source code of the compiler is available (but not free/libre). -- http://sourceware.org/bugzilla/show_bug.cgi?id=10126 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
