Re: PR25993, read of freed memory

[Simon Marchi <simark@simark.ca>]

On 2020-05-19 7:40 p.m., Alan Modra wrote:
> On Tue, May 19, 2020 at 09:27:15AM -0400, Simon Marchi wrote:
>> On 2020-05-19 12:32 a.m., Alan Modra via Gdb-patches wrote:
>>> -void bfd_set_filename (bfd *abfd, char *filename);
>>> +char *bfd_set_filename (bfd *abfd, const char *filename);
>> Should this return a `const char *`, just like bfd_get_filename?
>>
>> I haven't inspected all call sites, but it sounds like the caller
>> shouldn't be able to modify the filename contents.
> Yes, I've updated the return type.  One minor change needed to
> mach-o.c.
> 
>> Since the string gets copied by bfd_set_filename, let's use std::string
>> to avoid having to free:
> Done, and symfile-mem.c updated as per down-thread suggestion to make
> name a const char*.
> 
> I've left the return status from bfd_set_filename in gdb unchecked,
> ie. the out-of-memory NULL return, since it seems to me that not
> getting the expected name change is a minor detail very likely to be
> lost in some later OOM.

That LGTM for the GDB side, but I get a build failure in bfd/archive.c.  I think
bfd-in2.h needs to be regenerated?  Or maybe in BFD you don't typically include
re-generated files in your patches?

Simon