This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [10/19] record_line
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: eliz at gnu dot org
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 8 Jun 2009 16:53:23 +0200 (CEST)
- Subject: Re: [10/19] record_line
Eli Zaretskii wrote:
> > Date: Fri, 5 Jun 2009 23:18:16 +0200 (CEST)
> > From: "Ulrich Weigand" <uweigand@de.ibm.com>
> >
> > the record_line routine calls gdbarch_addr_bits_remove on the PC it is
> > passed. As there is no appropriate objfile at hand in this routine,
> > the following patch moves this operation up into the callers of record_line,
> > which will use the objfile architecture of the file they are processing.
>
> Maybe I'm missing something, but isn't this rather inelegant? We are
> moving some detail that is private to record_line into its callers,
> just because record_line doesn't know the architecture nor the objfile
> to get the architecture from? Why not simply pass the architecture or
> the objfile to record_line instead?
Well, I guess I didn't really express this in the patch email, but it seemed
to me that calling gdbarch_addr_bits_remove should't really be a private
detail of record_line. IMO this routine should simply take an actual PC
as input, as its comment states -- whatever hacks are required to compute
an actual PC value from information found in the object file should be done
in the symbol readers themselves (this might actually depend on the format).
For the purposes of this patch series, passing an objfile in to record_line
would work for me as well. It just didn't seem quite the right thing ..
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com