From: Luis Machado <lgustavo@codesourcery.com>
To: Doug Gilmore <Doug.Gilmore@imgtec.com>,
Simon Marchi <simon.marchi@polymtl.ca>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix PR 21337 v2: segfault when re-reading symbols with remote debugging.
Date: Sat, 29 Apr 2017 01:13:00 -0000 [thread overview]
Message-ID: <d7c8ab87-8e4e-30ad-918f-29c56ee97988@codesourcery.com> (raw)
In-Reply-To: <d266f2a4-5482-6178-f4fd-9280e27757b4@imgtec.com>
On 04/28/2017 06:44 PM, Doug Gilmore wrote:
>> ...
>> /* We use the same section offsets as from last time. I'm not
>> sure whether that is always correct for shared libraries. */
>> objfile->section_offsets = (struct section_offsets *)
>> obstack_alloc (&objfile->objfile_obstack,
>> SIZEOF_N_SECTION_OFFSETS (num_offsets));
>> memcpy (objfile->section_offsets, offsets,
>> SIZEOF_N_SECTION_OFFSETS (num_offsets));
>> objfile->num_sections = num_offsets;
>>
>> so it should not be the culprit... The s variable itself should point to an instance of obj_section, contained in the objfile_pspace_info::sections array. This one is allocated with XNEWVEC, so it shouldn't be affected by the fact that we clear the obstack.
>>
>> The objfile object itself doesn't change address, so the pointers to it should still be valid...
>>
>> I find the obj_section_addr and obj_section_offset very bad for readability and debuggability. Could you change them for inline functions that are not one liners? Then it will be obvious in the backtrace which operation causes the crash.
>>
>> Thanks,
>>
>> Simon
> Hi Simon,
>
> After thinking about it my comment and code placement wasn't
> particularly good. Something along the line's of Luis's change
> is better.
>
> Does Luis's comment address the question you have?
>
> If so, Luis: Should is it OK we incorporate your changes in the patch?
Sure. I have no problems with that.
next prev parent reply other threads:[~2017-04-29 1:13 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-31 23:04 [PATCH] [mips] Fix PR 21337 v1: " Doug Gilmore
2017-04-10 16:01 ` Doug Gilmore
2017-04-12 18:52 ` Luis Machado
2017-04-12 21:42 ` Doug Gilmore
2017-04-13 18:56 ` [PATCH] Fix PR 21337 v2: " Doug Gilmore
2017-04-14 15:33 ` Luis Machado
2017-04-22 2:15 ` Simon Marchi
2017-04-25 18:16 ` Doug Gilmore
2017-04-27 19:46 ` Simon Marchi
2017-04-28 23:44 ` Doug Gilmore
2017-04-29 1:13 ` Luis Machado [this message]
2017-04-29 1:42 ` Simon Marchi
2017-04-29 17:12 ` Doug Gilmore
2017-04-29 23:26 ` Simon Marchi
2017-04-30 5:14 ` Doug Gilmore
2017-05-10 23:26 ` Doug Gilmore
2017-05-12 3:29 ` Simon Marchi
2017-05-12 19:24 ` Doug Gilmore
2017-05-16 23:11 ` [PATCH] Fix PR 21337 (v3): " Doug Gilmore
2017-06-06 16:08 ` [PING][PATCH] " Doug Gilmore
2017-06-23 18:20 ` [PING^2][PATCH] " Doug Gilmore
2017-06-25 11:25 ` [PATCH] " Simon Marchi
2017-06-27 17:29 ` [PATCH] Fix PR 21337 (v4): " Doug Gilmore
2017-06-27 21:35 ` Doug Gilmore
2017-06-28 2:01 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d7c8ab87-8e4e-30ad-918f-29c56ee97988@codesourcery.com \
--to=lgustavo@codesourcery.com \
--cc=Doug.Gilmore@imgtec.com \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox