View Issue Details

IDProjectCategoryView StatusLast Update
0015693CentOS-7glibcpublic2019-07-19 11:10
Reporterautkin_undo 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version7.6.1810 
Target VersionFixed in Version 
Summary0015693: %si instead of %esi in init_complete SDT probe arg fails GDB solib event handler
DescriptionDue to reasons which are still under investigations, an update from glibc-2.17-222 to glibc-2.17-260 on CentOS 7 causes a regression in our slightly patched GDB. There is no known regression in vanilla GDB of any version (tested 7.6.1, 8.1, git master), but I hope you may want to look into the issue regardless.

The observable difference between old (good) and new (bad) version is in the .note.stapsdt section of /lib/ld-linux.so.2, namely, init_complete entry. It contains parameters, which are evaluated by GDB.
In old (good) version, the value is -4@$0 4@%esi;
In new (bad) version, the value is -4@$0 4@%si.

When GDB (version 8.1 to be specific here) executes svr4_handle_solib_event() on init_complete event, it compares `debug_base` which is the evaluated second argument from the supplied expression (e.g. `4@%esi`) to info->debug_base which is derived in a different way, and if those don't match, nothing happens. In old version, they did match, while in new version, they don't. The expression evaluates to either lowest 16 bits of the other value, or equates to lowest 16 bits of the other value, and having highest 16 bits set.

E.g. info->debug_base is 0xf7ffd8e4, while debug_base (coming from SDT probe marker argument) is 0xffffd8e4.
Or, in another instance, info->debug_base is 0xf7f958e4, while debug_base is 0x58e4.

I suppose %si is being evaluated as 16-bit value. The only way I can explain the high bits set is that the highest bit is treated as "sign bit" and is expanded to 16 highest bits of 32-bit-sized result value.

I looked at the changes between 2.17-222 and 2.17-260, https://git.centos.org/commit/rpms!glibc.git/c6d234388b93449ca43dde6a98575b2035272776 . I don't have any theory what caused the issue. Maybe it's one of 255 new patches, but it could also be an update in the toolchain used to build the glibc package.

Thanks in advance for looking.
Additional InformationContents of section .note.stapsdt:

New (bad):
 0000 08000000 30000000 03000000 73746170 ....0.......stap
 0010 73647400 39390000 40e80100 00000000 sdt.99..@.......
 0020 72746c64 00696e69 745f7374 61727400 rtld.init_start.
 0030 2d344024 30203440 2d343139 36282565 -4@$0 4@-4196(%e
 0040 62702900 08000000 2b000000 03000000 bp).....+.......
 0050 73746170 73647400 c53f0000 40e80100 stapsdt..?..@...
 0060 00000000 72746c64 00696e69 745f636f ....rtld.init_co
 0070 6d706c65 7465002d 34402430 20344025 mplete.-4@$0 4@%
 0080 73690000 08000000 33000000 03000000 si......3.......

Old (good):
 0000 08000000 30000000 03000000 73746170 ....0.......stap
 0010 73647400 f9370000 00ea0100 00000000 sdt..7..........
 0020 72746c64 00696e69 745f7374 61727400 rtld.init_start.
 0030 2d344024 30203440 2d343139 36282565 -4@$0 4@-4196(%e
 0040 62702900 08000000 2c000000 03000000 bp).....,.......
 0050 73746170 73647400 853e0000 00ea0100 stapsdt..>......
 0060 00000000 72746c64 00696e69 745f636f ....rtld.init_co
 0070 6d706c65 7465002d 34402430 20344025 mplete.-4@$0 4@%
 0080 65736900 08000000 33000000 03000000 esi.....3.......

GDB call stack for svr4_handle_solib_event():

#0 svr4_handle_solib_event () at solib-svr4.c:1887
#1 0x0000000000615726 in handle_solib_event () at solib.c:1291
#2 0x00000000004db7cd in bpstat_stop_status (aspace=<optimized out>, bp_addr=bp_addr@entry=4160184261, ptid=..., ws=ws@entry=0x7ffcef32e850) at breakpoint.c:5459
#3 0x000000000059af33 in handle_signal_stop (ecs=ecs@entry=0x7ffcef32e830) at infrun.c:5949
#4 0x000000000059c508 in handle_inferior_event_1 (ecs=0x7ffcef32e830) at infrun.c:5379
#5 handle_inferior_event (ecs=ecs@entry=0x7ffcef32e830) at infrun.c:5414
#6 0x000000000059d9e3 in fetch_inferior_event (client_data=<optimized out>) at infrun.c:3930
#7 0x000000000055c2fd in gdb_wait_for_event (block=block@entry=0) at event-loop.c:859
#8 0x000000000055c518 in gdb_do_one_event () at event-loop.c:322
#9 0x000000000055c595 in start_event_loop () at event-loop.c:371
#10 0x00000000005b2ce8 in captured_command_loop () at main.c:329
#11 0x00000000005b3b2d in captured_main (data=0x7ffcef32e960) at main.c:1156
#12 gdb_main (args=args@entry=0x7ffcef32ea90) at main.c:1172
#13 0x0000000000408b45 in main (argc=<optimized out>, argv=<optimized out>) at gdb.c:32

Our GDB patch:

diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index 909dfb7..bdef169 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -144,12 +144,12 @@ struct probe_info

 static const struct probe_info probe_info[] =
 {
- { "init_start", DO_NOTHING },
+ { "init_start", FULL_RELOAD },
   { "init_complete", FULL_RELOAD },
   { "map_start", DO_NOTHING },
   { "map_failed", DO_NOTHING },
   { "reloc_complete", UPDATE_OR_RELOAD },
- { "unmap_start", DO_NOTHING },
+ { "unmap_start", FULL_RELOAD },
   { "unmap_complete", FULL_RELOAD },
 };
TagsNo tags attached.
abrt_hash
URL

Activities

autkin_undo

autkin_undo

2019-01-10 16:46

reporter   ~0033558

The issue affects glibc.i686 package. In our usecase, we install it on x86_64 host to trace 32-bit debuggee program. The file to look at is /lib/ld-linux.so.2.
fweimer

fweimer

2019-07-19 11:09

reporter   ~0034849

This was fixed upstream in GDB:

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

Issue History

Date Modified Username Field Change
2019-01-10 16:40 autkin_undo New Issue
2019-01-10 16:46 autkin_undo Note Added: 0033558
2019-07-19 11:09 fweimer Note Added: 0034849
2019-07-19 11:10 TrevorH Status new => closed
2019-07-19 11:10 TrevorH Resolution open => fixed