[Bug libdw/30948] New: src/stack doesn't show source inforamtion if the target is compiled with clang

2023-10-08 Thread yamato at redhat dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=30948

Bug ID: 30948
   Summary: src/stack doesn't show source inforamtion if the
target is compiled with clang
   Product: elfutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: libdw
  Assignee: unassigned at sourceware dot org
  Reporter: yamato at redhat dot com
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

dwfl_module_getsrc() doesn't work unexpectedly if the target
executable is compiled with clang though it works well with an
executable compiled with gcc.

For testing I used executables built from the following source code (target.c):

static int
f1(void)
{
  while (1);
  return 0;
}

static int
f0(void)
{
  return f1();
}

int main(void)
{
  return f0();
}

I made two executables with two compilers.
  $ gcc -O0 -g target.c -o target-gcc
  $ clang -O0 -g target.c -o target-clang

I run the two executables in background:

$ ./target-gcc &  
[2] 2118229

$ ./target-clang & 
[3] 2118253

I run src/stack with -s -p options:


For the executable built with gcc, backtrace reported source lines.

$ ./src/stack -s -p 2118229
PID 2118229 - process
TID 2118229:
#0  0x0040110a f1
/home/yamato/var/elfutils/tests/target.c:4:9
#1  0x00401115 f0
/home/yamato/var/elfutils/tests/target.c:11:10
#2  0x00401120 main
/home/yamato/var/elfutils/tests/target.c:16:10
#3  0x7f7d6c823b8a __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58:16
#4  0x7f7d6c823c4b __libc_start_main@@GLIBC_2.34
../csu/libc-start.c:360:3
#5  0x00401045 _start


For the executable built with clang, backtrace didn't report source lines.

$ ./src/stack -s -p 2118253
PID 2118253 - process
TID 2118253:
#0  0x00401149 f1
#1  0x00401139 f0
#2  0x00401124 main
#3  0x7f4a84ab5b8a __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58:16
#4  0x7f4a84ab5c4b __libc_start_main@@GLIBC_2.34
../csu/libc-start.c:360:3
#5  0x00401045 _start

The bt command of Gdb can report them:

$ ./target-clang &
[1] 2116805
[yamato@dev64]~/var/elfutils/tests% pstack 2116805
#0  0x00401149 in f1 () at target.c:4
#1  0x00401139 in f0 () at target.c:11
#2  0x00401124 in main () at target.c:16

Gdb can report the source lines. So I guess clang injected enough information
to the executable.

The versions of the compilers:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230728 (Red Hat 13.2.1-1) (GCC)

$ clang -v
clang version 16.0.6 (Fedora 16.0.6-3.fc38)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation:
/usr/bin/../lib/gcc/x86_64-redhat-linux/13
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/13
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

The revision of elfutils: 557aa6a4b7b1d678b7c2c3b9aae1dafcc2160c64 (git
commit).

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

Re: Updating mailman settings to avoid From rewriting

2023-10-08 Thread Mark Wielaard
Hi,

On Sat, Oct 07, 2023 at 03:20:55PM +0300, Benson Muite wrote:
> On 10/7/23 06:55, Thiago Jung Bauermann wrote:
> > Mark Wielaard  writes:
> >>> Also the newlib and gdb-patches mailinglists don't have an admin at
> >>> the moment. Could someone volunteer to act as list admin for these?
> >>
> >> We still need admins/moderators for these two lists.
> > 
> > I'm not a maintainer or anything in GDB nor GNU, but if that isn't a
> > prerequisite and if other people are OK with it I'd be happy to be list
> > admin for gdb-patches.
> > 
> Would be happy to help with newlib

That would be nice. Note that it can be a shared responsibility. And
it isn't really much work. Two or three times a month there is spam
(most is filtered out before it hits the list) or a message that is
too big gets caught in moderation. And you can block people from
posting to the list in an emergency (or when gdb or newlib has a code
of conduct committee, when they decide to give someone a
timeout). Although that last one luckily only happens once every
couple of years.

If none of the gdb or newlib maintainers objects I can add you and
sent you the list password. Please sent me your PGP key if you have
one so I can sent you the authentication details in private.

Cheers,

Mark