)]}' { "commit": "e855469f9d4c49ffadc1a1bd06256c6617b5fbb5", "tree": "dcf36c96fa398e29eaa4c4980ec7453e0d935fc8", "parents": [ "6b2a22741b5aeda266a961a6f5f805e110dd8dd6" ], "author": { "name": "Jan Vrany", "email": "jan.vrany@labware.com", "time": "Mon Dec 08 17:47:04 2025 +0000" }, "committer": { "name": "Jan Vrany", "email": "jan.vrany@labware.com", "time": "Mon Dec 22 12:54:52 2025 +0000" }, "message": "Revert \"gdb: change blockvector::contains() to handle blockvectors with \"holes\"\"\n\nThis reverts commit cc1fc6af4150b19f9c4c70d0463ff498703fb637, since it\ncauses a number of regressions that seem not to be easily fixable.\n\nThe problem lies in existence of \"freestanding\" code, a code that is\npart of a CU but does not have any block associated with it. Consider\nfollowing program:\n\n __asm__(\n \".type foo,@function \\n\"\n \"foo: \\n\"\n \" mov %rdi, %rax \\n\"\n \" ret \\n\"\n );\n\n static int foo(int i);\n\n int main(int argc, char **argv) {\n return foo(argc);\n }\n\nWhen compiled, the foo function has no block of itself:\n\n Blockvector:\n\n no map\n\n block #000, object at 0x55978957b510, 1 symbols in 0x1129..0x1148\n int main(int, char **); block object 0x55978957b380, 0x112d..0x1148 section .text\n block #001, object at 0x55978957b470 under 0x55978957b510, 2 symbols in 0x1129..0x1148\n typedef int int;\n typedef char char;\n block #002, object at 0x55978957b380 under 0x55978957b470, 2 symbols in 0x112d..0x1148, function main\n int argc; computed at runtime\n char **argv; computed at runtime\n\nIn this case lookup(0x1129) returns static block and, because of the\nchange in cc1fc6af4, contains(0x1129) which is wrong.\n\nSuch \"freestanding\" code is perhaps not common but it does exist,\nespecially in system code. In fact the regressions were at least in part\ncaused by such \"freestanding\" code in glibc (libc_sigaction.c).\n\nThe whole idea of commit cc1fc6af4 was to handle \"holes\" in CUs, a case\nwhere one CU spans over multiple disjoint regions, possibly interleaved\nwith other CUs. Consider somewhat extreme case with two CUs:\n\n /* hole-1.c */\n int give_me_zero ();\n\n int\n main ()\n {\n return give_me_zero ();\n }\n\n /* hole-2.c */\n int __attribute__ ((section (\".text_give_me_one\"))) __attribute__((noinline))\n baz () { return 42; }\n\n __asm__(\n \".section .text_give_me_one,\\\"ax\\\",@progbits\\n\"\n \".type foo,@function \\n\"\n \"foo: \\n\"\n \" mov %rdi, %rax \\n\"\n \" ret \\n\"\n \" nop \\n\"\n \" nop \\n\"\n \" nop \\n\"\n );\n int __attribute__ ((section (\".text_give_me_one\"))) __attribute__((noinline))\n give_me_one ()\n {\n return 1;\n }\n\n __asm__(\n \".section .text_give_me_zero,\\\"ax\\\",@progbits\\n\"\n \"bar: \\n\"\n \" jmp give_me_one \\n\"\n \" nop \\n\"\n \" nop \\n\"\n \" nop \\n\"\n );\n int __attribute__ ((section (\".text_give_me_zero\")))\n give_me_zero ()\n {\n extern int bar();\n return give_me_one() - 1;\n }\n\nThis when compiled with a carefully crafted linker script to force code\nat certain positions, creates following layout:\n\n 0x080000..0x080007 # \"freestanding\" bar from hole-2.c\n 0x080008..0x080016 # give_me_zero() from hole-2.c\n 0x080109..0x080114 # main from hole-1.c\n 0xf00000..0xf0000b # baz() from hole-2.c\n 0xf0000b..0xf00011 # \"freestanding\" foo from hole-2.\n 0xf0000b..0xf0001c # gice_me_one() from hole-2.\n\nThe block vector for hole-1.c looks:\n\n Blockvector:\n\n no map\n\n block #000, object at 0x555a5d85fb90, 1 symbols in 0x80109..0x80114\n int main(void); block object 0x555a5d85faa0, 0x80109..0x80114 section .text\n block #001, object at 0x555a5d85faf0 under 0x555a5d85fb90, 1 symbols in 0x80109..0x80114\n typedef int int;\n block #002, object at 0x555a5d85faa0 under 0x555a5d85faf0, 0 symbols in 0x80109..0x80114, function main\n\nAnd for hole-2.c:\n\n Blockvector:\n\n map\n 0x0 -\u003e 0x0\n 0x80008 -\u003e 0x555a5d85ff50\n 0x80016 -\u003e 0x0\n 0xf00000 -\u003e 0x555a5d860280\n 0xf0000b -\u003e 0x0\n 0xf00012 -\u003e 0x555a5d860110\n 0xf0001d -\u003e 0x0\n\n block #000, object at 0x555a5d8603b0, 3 symbols in 0x80008..0xf0001d\n int give_me_zero(void); block object 0x555a5d85ff50, 0x80008..0x80016 section .text\n int give_me_one(void); block object 0x555a5d860110, 0xf00012..0xf0001d section .text\n int baz(void); block object 0x555a5d860280, 0xf00000..0xf0000b section .text\n block #001, object at 0x555a5d8602d0 under 0x555a5d8603b0, 1 symbols in 0x80008..0xf0001d\n typedef int int;\n block #002, object at 0x555a5d85ff50 under 0x555a5d8602d0, 0 symbols in 0x80008..0x80016, function give_me_zero\n block #003, object at 0x555a5d860280 under 0x555a5d8602d0, 0 symbols in 0xf00000..0xf0000b, function baz\n block #004, object at 0x555a5d860110 under 0x555a5d8602d0, 0 symbols in 0xf00012..0xf0001d, function give_me_one\n\nNote that despite the fact \"freestanding\" bar belongs to hole-2.c, the\ncorresponding CU\u0027s global and static blocks start at 0x80008! Looking\nat DWARF for the second program, it looks like that the compiler (GCC 15)\ndid not record the presence of \"freestanding\" code:\n\n \u003c0\u003e\u003c71\u003e: Abbrev Number: 1 (DW_TAG_compile_unit)\n \u003c72\u003e DW_AT_producer : (indirect string, offset: 0): GNU C23 15.2.0 -mtune\u003dgeneric -march\u003dx86-64 -g -fasynchronous-unwind-tables\n \u003c76\u003e DW_AT_language : 29 (C11)\n \u003c77\u003e Unknown AT value: 90: 3\n \u003c78\u003e Unknown AT value: 91: 0x31647\n \u003c7c\u003e DW_AT_name : (indirect line string, offset: 0x2d): hole-2.c\n \u003c80\u003e DW_AT_comp_dir : (indirect line string, offset: 0): test_programs\n \u003c84\u003e DW_AT_ranges : 0xc\n \u003c88\u003e DW_AT_low_pc : 0\n \u003c90\u003e DW_AT_stmt_list : 0x51\n\nand corresponding part of .debug_aranges:\n\n Length: 76\n Version: 2\n Offset into .debug_info: 0x65\n Pointer Size: 8\n Segment Size: 0\n\n Address Length\n 0000000000f00000 000000000000000b\n 0000000000f00012 000000000000000b\n 0000000000080008 000000000000000e\n 0000000000000000 0000000000000000\n\nThiago suggested to use minsymbols to tell whether or a CU contains\ngiven address. I do not think this would work reliably as minsymbols do\nno know to which CU they belong. In slightly more complicated case of\ninterleaved CUs it does not seem to be possible to tell for sure to which\none a given minsymbol belongs.\n\nMoreover, Tom suggested that the comment in find_compunit_symtab_for_pc_sect\n(which led to cc1fc6af4) may be outdated [2].\n\nGiven all that, I\u0027m just reverting the change.\n\n[1]: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d33679#c13\n[2]: https://inbox.sourceware.org/gdb-patches/87cy6xzd3j.fsf@tromey.com/\n\nApproved-By: Tom Tromey \u003ctom@tromey.com\u003e\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d33679\n", "tree_diff": [ { "type": "modify", "old_id": "f5883f18660c0b705bd97334e60ae769dc132443", "old_mode": 33188, "old_path": "gdb/block-selftests.c", "new_id": "19e2a6d8db3c1fdcd4060e40a54c05087946eadc", "new_mode": 33188, "new_path": "gdb/block-selftests.c" }, { "type": "modify", "old_id": "3d2c51cc554af572c08a1173e25bc8833bb8fc54", "old_mode": 33188, "old_path": "gdb/block.c", "new_id": "e21580bcf6394642660f35622c7f6fcdaf24da1b", "new_mode": 33188, "new_path": "gdb/block.c" } ] }