This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 8/8] [PowerPC] Recognize isa205 in linux core files


Ulrich Weigand <uweigand@de.ibm.com> writes:

> Pedro Franco de Carvalho wrote:
>> Ulrich Weigand <uweigand@de.ibm.com> writes:
>> 
>> > Maybe this routine should now be moved to ppc-linux-tdep.c ...
>> >
>> >> +  CORE_ADDR hwcap = 0;
>> >> +
>> >> +  target_auxv_search (target, AT_HWCAP, &hwcap);
>> >> +
>> >> +  features.isa205 = ppc_linux_has_isa205 (hwcap);
>> >
>> > ... so it can be reused here?
>> >
>> > Otherwise this looks OK to me.
>> 
>> Should the routine take a struct target_ops * parameter, so that
>> core_read_description can pass its target (for calling
>> target_auxv_search)? In this case all the calls in ppc_linux_nat.c would
>> also have to be updated.
>
> Right, I guess that makes sense.
>
> (Another question is why ppp-linux-nat.c repeats this call all the
> time, maybe it would be better to cache the result per inferior ...
> But that's certainly a separate issue.)

Now I'm confused as to which target should be passed to
target_auxv_search. It uses the target parameter for reading the auxv
data but then it calls target_auxv_parse through the global
target_stack.

Should ppc-linux-tdep also also pass target_stack in
core_read_description, for consistency?

Or should ppc-linux-nat be changed to pass "this"? I can do this either
by moving ppc_linux_get_hwcap to ppc-linux-tdep.c and adding a target
parameter, and then change all the call sites in ppc-linux-nat.c, or I
can make ppc_linux_get_hwcap a private method of ppc_linux_nat_target
and pass "this" inside it (which wouldn't require changing the call
sites), and leave the bare call to target_auxv_search in
ppc-linux-tdep.c.

I haven't changed this in v2 yet. I did change how an error is checked
and handled to make it more explicit.

And it turns out that target_auxv_search already caches the whole auxv
for each inferior. This part could still be improved because
ppc_linux_nat_target::auxv_parse calls ppc_linux_target_wordsize (which
issues a ptrace call) a second time, and at the point were it is
called the wordsize is already known, but it's not clear how to pass the
wordsize to auxv_parse in read_description.

Thanks!
Pedro


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]