This is the mail archive of the gdb-patches@sourceware.cygnus.com 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]

Re: Regression caused by elfread.c patch


   From: "Amit S. Kale" <akale@veritas.com>
   Organization: Veritas Software (India)
   Date: Tue, 15 Feb 2000 13:56:11 +0530
   Cc: akale@veritas.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com,
      gdb-patches@sourceware.cygnus.com
   Content-Type: text/plain

   Hi,

   On Tue, 15 Feb 2000, Jim Kingdon wrote:
   > > That was because Jim didn't checkin my patch correctly.
   > > He has fixed it now.
   > 
   > No, this is a different problem.

   Apolgies to Jim, because the problem was not his fault as said by me.

   > I don't see how your patch could work at all - sym->section->index is
   > a very different number than a SECT_OFF_* code.  The SECT_OFF_* code
   > (which gets fed to ANOFFSET) isn't computed until later in the
   > function (via the call to record_minimal_symbol_and_info).

   The patch I sent is working in some configurations. I have been
   using it for debugging linux kernel. This patch was needed to load
   module object files using 'add-symbol-file' after loading kernel
   object file using 'symbol-file'.

So kernel modules are using different offsets for .text and .data huh.

   I guess gdb first prepares text, data, bss segments and following
   code bfd/section.c:bfd_make_section_anyway():
	   newsect->index = abfd->section_count++;
   indicates that section->index contains SECT_OFF_* codes when
   segments are loaded. This may not have been designed this way, but
   it seems to be that way.

I don't think the above is true.

   Using sym->section->index is not right for segments that are not
   text or data segments. Using sym->section->index should be all
   right for data segments.

Using sym->sections->index is not right for any section.  It just
happens to be right for kernel modules where the numbering of .text,
.data and .bss is identical to the SECT_OFF_* codes.  In my libc .text
is section 16 (at least for a computer scientist :)) and .data is 20.
So sym->sections->index cannot be used without fixing a lot of other
code.

   I suggest following patch. I have verified that the vfprintf
   problem reported by Mark does not appear with this patch. I haven't
   tested it with test suite.

Apart from the fact that your patch is reversed, this isn't the right
solution.  Now GDB will be unable to find symbols in the data
section.  You probaby can get away with using SECT_OFF_DATA instead of
sym->section->index, but that might not work for .bss in kernel
modules, and I don't think we should accept that patch without at
least some comments about this braindamage.

Mark

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