https://sourceware.org/bugzilla/show_bug.cgi?id=21943
Yao Qi changed:
What|Removed |Added
Host||x86_64-pc-linux-gnu
--
You are receiving th
Assignee: unassigned at sourceware dot org
Reporter: qiyao at gcc dot gnu.org
Target Milestone: ---
$ valgrind --leak-check=full ./objdump -d /tmp/1.x86.exe
==20024== 50 bytes in 1 blocks are definitely lost in loss record 1 of 1
==20024==at 0x4C2AB80: malloc (in
/usr/lib
https://sourceware.org/bugzilla/show_bug.cgi?id=20946
--- Comment #2 from Yao Qi ---
Hi Nick,
the patch works!
(gdb) set architecture fr300
The target architecture is assumed to be fr300
(gdb) disassemble 0,+4
Dump of assembler code from 0x0 to 0x4:
0x: Cannot access memory at addre
Assignee: unassigned at sourceware dot org
Reporter: qiyao at gcc dot gnu.org
Target Milestone: ---
I configured gdb with all targets enabled "--enable-targets=all
--enable-64-bit-bfd --disable-binutils --disable-gprof --disable-gold
--disable-gas --disable-ld".
I
https://sourceware.org/bugzilla/show_bug.cgi?id=16910
--- Comment #1 from Yao Qi ---
Created attachment 7587
--> https://sourceware.org/bugzilla/attachment.cgi?id=7587&action=edit
dwz.S
$ cat 1.c
int
main (void)
{
return 0;
}
$ cat 2.c
int
__wrap_main (void)
{
__real_main ();
return 0
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: qiyao at gcc dot gnu.org
We find this bug when we run gdb test gdb.dwarf2/dwz.exp. Here are the steps
to reproduce this bug:
1. Compile and link
$ gcc 1.c -c -o 1.o
