~ubuntu-support-team/binutils/+git/binutils-gdb:users/roland/gprofng-zlib

Last commit made on 2022-03-16
Get this branch:
git clone -b users/roland/gprofng-zlib https://git.launchpad.net/~ubuntu-support-team/binutils/+git/binutils-gdb

Branch merges

Branch information

Name:
users/roland/gprofng-zlib
Repository:
lp:~ubuntu-support-team/binutils/+git/binutils-gdb

Recent commits

8e4e389... by Roland McGrath <email address hidden>

wip

260ecdc... by Fangrui Song <email address hidden>

objcopy --weaken-symbol: apply to STB_GNU_UNIQUE symbols

    PR binutils/28926
    * objcopy.c (filter_symbols): Apply weaken to STB_GNU_UNIQUE symbols
    * NEWS: Mention feature.
    * testsuite/binutils-all/objcopy.exp (objcopy_test_symbol_manipulation): New test.
    * testsuite/binutils-all/weaken-gnu-unique.s: New.

b1b9c41... by Tom Tromey <email address hidden>

Reimplement array concatenation for Ada and D

This started as a patch to implement string concatenation for Ada.
However, while working on this, I looked at how this code could
possibly be called. It turns out there are only two users of
concat_operation: Ada and D. So, in addition to implementing this for
Ada, this patch rewrites value_concat, removing the odd "concatenate
or repeat" semantics, which were completely unused. As Ada and D both
seem to represent strings using TYPE_CODE_ARRAY, this removes the
TYPE_CODE_STRING code from there as well.

a73c128... by Tom Tromey <email address hidden>

Remove eval_op_concat

eval_op_concat has code to search for an operator overload of
BINOP_CONCAT. However, the operator overloading code is specific to
C++, which does not have this operator. And,
binop_types_user_defined_p rejects this case right at the start, and
value_x_binop does not handle this case. I think this code has been
dead for a very long time. This patch removes it and hoists the
remaining call into concatenation::evaluate, removing eval_op_concat
entirely.

fc18a21... by Tom Tromey <email address hidden>

Ada support for wide strings

This adds some basic support for Wide_String and Wide_Wide_String to
the Ada expression evaluator. In particular, a string literal may be
converted to a wide or wide-wide string depending on context.

The patch updates an existing test case. Note that another test,
namely something like:

    ptype Wide_Wide_String'("literal")

... would be nice to add, but when tested against a distro GNAT, this
did not work (probably due to lack of debuginfo); so, I haven't
included it here.

16b6c36... by Tom Tromey <email address hidden>

Remove eval_op_string

eval_op_string is only used in a single place -- the implementation of
string_operation. This patch turns it into the
string_operation::evaluate method, removing a bit of extraneous code.

879f2aa... by Carl Love <email address hidden>

Powerpc fix for gdb.base/ending-run.exp

The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the
system does not have the needed glibc debug-info files loaded. In this
case, gdb is not able to determine where execution stopped. This behavior
looks as follows for the test case:

The next to the last test does a next command when the program is stopped
at the closing bracket for main. The message printed is:

0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6

which fails to match any of the test_multiple options.

The test then does another next command. On Powerpc, the
message printed it:

Cannot find bounds of current function

The test fails as the output does not match any of the options for the
gdb_test_multiple.

I checked the behavior on Powerpc to see if this is typical.
I ran gdb on the following simple program as shown below.

#include <stdio.h>
int
main(void)
{
  printf("Hello, world!\n");
  return 0;
}

gdb ./hello_world
<snip the gdb start info>

Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello_world...
(No debugging symbols found in ./hello_world)
(gdb) break main
Breakpoint 1 at 0x818
(gdb) r

Starting program: /home/carll/hello_world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x0000000100000818 in main ()
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Hello, world!
0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
(gdb) n
Cannot find bounds of current function

So it would seem that the messages seen from the test case are
"normal" output for Powerpc when the debug-info is not available.

The following patch adds the output from Powerpc as an option
to the gdb_test_multiple statement, identifying the output as the expected
output on Powerpc without the needed debug-info files installed.

The patch has been tested on a Power 10 system and an Intel
64-bit system. No additional regression failures were seen on
either platform.

d65c0dd... by Martin Storsjö

dlltool: Use the output name as basis for deterministic temp prefixes

 PR 28885
 * dlltool.c (main): use imp_name rather than dll_name when
 generating a temporary file name.

a2757c4... by Jan Vrany <email address hidden>

gdb/mi: consistently notify user when GDB/MI client uses -thread-select

GDB notifies users about user selected thread changes somewhat
inconsistently as mentioned on gdb-patches mailing list here:

  https://sourceware.org/pipermail/gdb-patches/2022-February/185989.html

Consider GDB debugging a multi-threaded inferior with both CLI and GDB/MI
interfaces connected to separate terminals.

Assuming inferior is stopped and thread 1 is selected, when a thread
2 is selected using '-thread-select 2' command on GDB/MI terminal:

    -thread-select 2
    ^done,new-thread-id="2",frame={level="0",addr="0x00005555555551cd",func="child_sub_function",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="30",arch="i386:x86-64"}
    (gdb)

and on CLI terminal we get the notification (as expected):

    [Switching to thread 2 (Thread 0x7ffff7daa640 (LWP 389659))]
    #0 child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30
    30 volatile int dummy = 0;

However, now that thread 2 is selected, if thread 1 is selected
using 'thread-select --thread 1 1' command on GDB/MI terminal
terminal:

   -thread-select --thread 1 1
   ^done,new-thread-id="1",frame={level="0",addr="0x0000555555555294",func="main",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="66",arch="i386:x86-64"}
   (gdb)

but no notification is printed on CLI terminal, despite the fact
that user selected thread has changed.

The problem is that when `-thread-select --thread 1 1` is executed
then thread is switched to thread 1 before mi_cmd_thread_select () is
called, therefore the condition "inferior_ptid != previous_ptid"
there does not hold.

To address this problem, we have to move notification logic up to
mi_cmd_execute () where --thread option is processed and notify
user selected contents observers there if context changes.

However, this in itself breaks GDB/MI because it would cause context
notification to be sent on MI channel. This is because by the time
we notify, MI notification suppression is already restored (done in
mi_command::invoke(). Therefore we had to lift notification suppression
logic also up to mi_cmd_execute (). This change in made distinction
between mi_command::invoke() and mi_command::do_invoke() unnecessary
as all mi_command::invoke() did (after the change) was to call
do_invoke(). So this patches removes do_invoke() and moves the command
execution logic directly to invoke().

With this change, all gdb.mi tests pass, tested on x86_64-linux.

Co-authored-by: Andrew Burgess <email address hidden>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20631

f4be268... by "H.J. Lu" <email address hidden>

gprofng: Use symver attribute if available

Use symver attribute if available, instead of asm statement, to support
LTO build.

 PR gprof/28962
 * libcollector/dispatcher.c (timer_create@@GLIBC_2.3.3): Use
 SYMVER_ATTRIBUTE.
 (timer_create@GLIBC_2.2): Likewise.
 (timer_create@GLIBC_2.2.5): Likewise.
 (pthread_create@@GLIBC_2.1): Likewise.
 (pthread_create@GLIBC_2.0): Likewise.
 * libcollector/iotrace.c (open64@@GLIBC_2.2): Likewise.
 (open64@GLIBC_2.1): Likewise.
 (fopen@@GLIBC_2.1): Likewise.
 (fopen@GLIBC_2.0): Likewise.
 (fclose@@GLIBC_2.1): Likewise.
 (fclose@GLIBC_2.0): Likewise.
 (fdopen@@GLIBC_2.1): Likewise.
 (fdopen@GLIBC_2.0): Likewise.
 (pread@@GLIBC_2.2): Likewise.
 (pread@GLIBC_2.1): Likewise.
 (pwrite@@GLIBC_2.2): Likewise.
 (pwrite@GLIBC_2.1): Likewise.
 (pwrite64@@GLIBC_2.2): Likewise.
 (pwrite64@GLIBC_2.1): Likewise.
 (fgetpos@@GLIBC_2.2): Likewise.
 (fgetpos@GLIBC_2.0): Likewise.
 (fgetpos64@@GLIBC_2.2): Likewise.
 (fgetpos64@GLIBC_2.1): Likewise.
 (fsetpos@@GLIBC_2.2): Likewise.
 (fsetpos@GLIBC_2.0): Likewise.
 (fsetpos64@@GLIBC_2.2): Likewise.
 (fsetpos64@GLIBC_2.1): Likewise.
 * libcollector/linetrace.c (posix_spawn@@GLIBC_2.15): Likewise.
 (posix_spawn@GLIBC_2.2): Likewise.
 (posix_spawn@GLIBC_2.2.5): Likewise.
 (posix_spawnp@@GLIBC_2.15): Likewise.
 (posix_spawnp@GLIBC_2.2): Likewise.
 (posix_spawnp@GLIBC_2.2.5): Likewise.
 (popen@@GLIBC_2.1): Likewise.
 (popen@GLIBC_2.0): Likewise.
 (_popen@@GLIBC_2.1): Likewise.
 (_popen@GLIBC_2.0): Likewise.
 * libcollector/mmaptrace.c (dlopen@@GLIBC_2.1): Likewise.
 (dlopen@GLIBC_2.0): Likewise.
 * libcollector/synctrace.c (pthread_cond_wait@@GLIBC_2.3.2):
 Likewise.
 (pthread_cond_wait@GLIBC_2.0): Likewise.
 (pthread_cond_wait@GLIBC_2.2.5): Likewise.
 (pthread_cond_wait@GLIBC_2.2): Likewise.
 (pthread_cond_timedwait@@GLIBC_2.3.2): Likewise.
 (pthread_cond_timedwait@GLIBC_2.0): Likewise.
 (pthread_cond_timedwait@GLIBC_2.2.5): Likewise.
 (pthread_cond_timedwait@GLIBC_2.2): Likewise.
 (sem_wait@@GLIBC_2.1): Likewise.
 (sem_wait@GLIBC_2.0): Likewise.
 * src/collector_module.h (SYMVER_ATTRIBUTE): New.