Well, the change in objdump output is purely cosmetic. For 32bit
object formats we just truncate the display now.
As an aside, is there an option to turn this truncation off? The vr5432
as and ld will still pass around 64 bit addresses.
On August 15, H.J. Lu applied a patch to 'gdb/dbxread.c' shown here:
diff -urN -x CVS work/gdb/dbxread.c gdb-5.0-08162001/gdb/dbxread.c
--- work/gdb/dbxread.c Tue Oct 30 16:33:33 2001
+++ gdb-5.0-08162001/gdb/dbxread.c Wed Aug 15 00:02:28 2001
@@ -951,7 +951,10 @@
(intern).n_type = bfd_h_get_8 (abfd, (extern)->e_type); \
(intern).n_strx = bfd_h_get_32 (abfd, (extern)->e_strx); \
(intern).n_desc = bfd_h_get_16 (abfd, (extern)->e_desc); \
- (intern).n_value = bfd_h_get_32 (abfd, (extern)->e_value); \
+ if (bfd_get_sign_extend_vma
+ (intern).n_value = bfd_h_get_signed_32 (abfd,
+ else \
+ (intern).n_value = bfd_h_get_32 (abfd, (extern)->e_value); \
> /* Invariant: The symbol pointed to by symbuf_idx is the first one
If I back out this change, my debug output is "correct", but I no longer
have the nice line numbers and files decoded for me:
If you back it out, I believe we just give up in confusion [:)] This is
int the reading of stabs info. breakinst has no stabs info, so it's
getting its line info somewhere else.
It might - assembler debugging ...
Please point me at a copy of your kernel binary with debug info, and
I'll look into it.
Yes, you want to look for a version of breakinst that isn't sign
extended. Since pulling the above patch helped it won't be in .stabs so
the symbol table?