This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 5/6] Add validity bits for psymtab high and low fields
- From: Keith Seitz <keiths at redhat dot com>
- To: Tom Tromey <tom at tromey dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 5 Jun 2018 10:38:52 -0700
- Subject: Re: [RFA 5/6] Add validity bits for psymtab high and low fields
- References: <20180503223621.22544-1-tom@tromey.com> <20180503223621.22544-6-tom@tromey.com> <9b460d82-3c69-21dd-eb9e-1c4598e8e9a8@redhat.com> <878t7t403p.fsf@tromey.com>
On 06/05/2018 10:25 AM, Tom Tromey wrote:
>>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:
> Also the final patch in this series changes this line to:
>
> if (PSYMTAB_RAW_TEXTHIGH (pst) == 0 && last_function_name
> && gdbarch_sofun_address_maybe_missing (gdbarch))
>
Sorry, I missed that. In that case, ignore my comment.
> Keith> There's also this line in dbx_read_symtab that might qualify (from case N_SCOPE):
>
> Keith> valu = nlist.n_value + last_function_start;
> Keith> if (PSYMTAB_TEXTHIGH (pst) == 0 || valu > PSYMTAB_TEXTHIGH (pst))
> Keith> SET_PSYMTAB_TEXTHIGH (pst, valu);
> Keith> break;
>
> This also gets changed to use the RAW_ forms.
Likewise.
> Keith> Also in this function, can textlow_not_set be replaced by
> Keith> textlow_valid? [The same with the textlow_not_set parameter to
> Keith> dbx_end_psymtab?]
>
> I think it is a good idea, but there is one spot setting textlow_not_set
> without invoking SET_PSYMTAB_TEXTLOW. From the N_SO case:
>
> prev_textlow_not_set = textlow_not_set;
>
> /* A zero value is probably an indication for the SunPRO 3.0
> compiler. dbx_end_psymtab explicitly tests for zero, so
> don't relocate it. */
>
> if (nlist.n_value == 0
> && gdbarch_sofun_address_maybe_missing (gdbarch))
> {
> textlow_not_set = 1;
> valu = 0;
> }
> else
> textlow_not_set = 0;
>
> I don't know anything about stabs, so my basic idea in this area was to
> make the changes as minimal as possible.
I should have looked a little more closely at the viability of my suggestion. I agree with you, erring on the side of minimal invasion in "obscure" code is always prudent.
Thank you for the explanations.
Keith