aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-varobj.c
diff options
context:
space:
mode:
authorAlan Modra <amodra@gmail.com>2024-12-16 07:45:34 +1030
committerAlan Modra <amodra@gmail.com>2024-12-16 09:13:16 +1030
commit35701ef3ea4a220d456d5ae1053a8630b24db388 (patch)
tree78431b520e4eed90321aef14212a572e05a159f2 /gdb/python/py-varobj.c
parent552ac612a3af0f11cbd0b2cad62e7952d401a268 (diff)
downloadgdb-35701ef3ea4a220d456d5ae1053a8630b24db388.zip
gdb-35701ef3ea4a220d456d5ae1053a8630b24db388.tar.gz
gdb-35701ef3ea4a220d456d5ae1053a8630b24db388.tar.bz2
Move modification of bfd abs and und back to gas
In commit f592407e4d75 I deleted gas' obj_sec_set_private_data, and instead put the gas modification of bfd's *ABS* and *UND* sections in bfd_make_section_old_way. More recently in commit 8b5a21249537 I made tekhex symbol creation use bfd_make_section_old_way for symbol sections. After that we saw numerous non-repeatable oss-fuzz reports of accesses to freed memory involving relocation symbols. I think what is happening is: A tekhex testcase with an absolute symbol is run through the tool, modifying bfd_abs_section.symbol to point to a symbol on the bfd's objalloc memory. On closing that bfd bfd_abs_section.symbol points to freed memory. A second testcase is run through the tool with some access to the *ABS* symbol. This triggers the invalid memory access. The same thing could happen if a user runs objdump or nm with two files on the command line, the first being a tekhex file with absolute symbols, or if ld is given tekhex input among other files. Clearly, it's a bad idea to modify the *ABS* or *UND* sections for input files. bfd/ * section.c (bfd_make_section_old_way): Don't call _new_section_hook for standard abs, com, und and ind sections. gas/ * as.c (bfd_std_section_init): New function. (perform_an_assembly_pass): Move section initialisation to.. (gas_init): ..here. Use bfd_std_section_init.
Diffstat (limited to 'gdb/python/py-varobj.c')
0 files changed, 0 insertions, 0 deletions