Re: [PATCH] RISC-V: Add untested 32-bit core file support.

2019-01-13 Thread Mark Wielaard 
On Sat, Jan 12, 2019 at 04:37:51PM -0800, Jim Wilson wrote:
> On Sat, Jan 12, 2019 at 2:29 PM Mark Wielaard  wrote:
> > > static const Ebl_Register_Location prstatus_regs[] =
> > >{
> > > -{ .offset = 8, .regno = 1, .count = 31, .bits = 64 } /* x1..x31 */
> > > +{ .offset = BITS/8, .regno = 1, .count = 31, .bits = 64 } /* x1..x31 
> > > */
> > >};
> >
> > Should that be .bits = BITS ?
> 
> Yes, sorry, I was looking at the offset field and completely missed
> the bits member at the end.  Do you want me to submit an updated
> patch?

I fixed it up and pushed the commit. It looks fine otherwise.

Thanks,

Mark

[Bug libdw/23981] dwarf_siblingof() fails with attribute form DW_FORM_ref_addr

2019-01-13 Thread mark at klomp dot org 
https://sourceware.org/bugzilla/show_bug.cgi?id=23981

--- Comment #4 from Mark Wielaard  ---
(In reply to Andreas Kromke from comment #3)
> I changed the source file accordingly, rebuilt the library and rerun the
> tests. The result is, unfortunately, the same, i.e. there is no improvement.
> 
> Analysis showed that in failure case these lines are executed:
> 
> if (sibattr.form == DW_FORM_ref_addr)
> and
> uint8_t ref_size;
> and
>   ref_size = cu->address_size;
> and
> __libdw_seterrno (DWARF_E_INVALID_DWARF);
> return -1;
> 
> So obviously the new code piece was run, but the failure was still detected
> later, in the old code.

This is really hard to debug with just this information and without the exact
DWARF that is being decoded. Could you please post an example DWARF description
and/or a backtrace when the error occurs/__libdw_seterrno is called?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libdw/23982] dwarf_formref_die() does not support DW_FORM_indirect

2019-01-13 Thread mark at klomp dot org 
https://sourceware.org/bugzilla/show_bug.cgi?id=23982

--- Comment #3 from Mark Wielaard  ---
As with your other bug without at least some example DWARF files this will be
somewhat hard to support. I think I know what would be needed, but without
actual testcases it will be hard to get right.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24068] readelf.c:10152:15: error: ‘%*llx’ directive output between 4 and 2147483647 bytes may cause result to exceed ‘INT_MAX’ [-Werror=format-overflow=] with -m32

2019-01-13 Thread mark at klomp dot org 
https://sourceware.org/bugzilla/show_bug.cgi?id=24068

Mark Wielaard  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-13
 CC||mark at klomp dot org
 Ever confirmed|0   |1

--- Comment #1 from Mark Wielaard  ---
This is weird. I cannot replicate with a standard build and gcc (GCC) 9.0.0
20190112 (experimental).

Aha, with -m32. hmmm. Odd.

So the issue seems to be that GCC doesn't realize digits is capped between 4
and 16. We could help with with something like:

diff --git a/src/readelf.c b/src/readelf.c
index 3a73710ff..83b700eee 100644
--- a/src/readelf.c
+++ b/src/readelf.c
@@ -10128,7 +10128,7 @@ print_debug_str_section (Dwfl_Module *dwflmod
__attribute__ ((unused)),
   ++digits;
   tmp >>= 4;
 }
-  digits = MAX (4, digits);
+  digits = MIN (16, MAX (4, digits));

   printf (gettext ("\nDWARF section [%2zu] '%s' at offset %#" PRIx64 ":\n"
   " %*s  String\n"),

I that the correct fix though? Or is something else going on?
I don't understand why this is -m32 specific.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

2019-01-13 Thread mark at klomp dot org 
https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #3 from Mark Wielaard  ---
Sorry, I have no idea what is going on.
It looks like a normal arm ELF file:

$ eu-readelf -h nm.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF32
  Data:  2's complement, little endian
  Ident Version: 1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  REL (Relocatable file)
  Machine:   ARM
  Version:   1 (current)
  Entry point address:   0
  Start of program headers:  0 (bytes into file)
  Start of section headers:  106424 (bytes into file)
  Flags: 0x500
  Size of this header:   52 (bytes)
  Size of program header entries:0 (bytes)
  Number of program headers entries: 0
  Size of section header entries:40 (bytes)
  Number of section headers entries: 31
  Section header string table index: 28

0x500 (which your eu-elflint complains about) is EF_ARM_EABI_VER5, which
the arm backend hook machine_flag_check knows about. So eu-elflint really
should have no complaints:

$ eu-elflint nm.o 
No errors

Maybe your installation isn't able to correctly load the ebl backends?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: RISC-V support

2019-01-13 Thread Jim Wilson 
On Sat, Jan 12, 2019 at 5:23 PM Kurt Roeckx  wrote:
> O32 really has at least the following variants:
> - O32 FP32
> - O32 FPXX
> - O32 FP64
> - O32 FP64A

The FPXX and FP64A stuff is new, after I stopped tracking MIPS stuff,
so I hadn't noticed it.  I see why they added these, but if you count
soft-float, single-float, no-float, and a now deprecated 64-bit FP reg
mode, there are 8 different ways to handle FP code for o32.  Crazy.
Most of them aren't relevant to linux though.  And I suppose 20-30
years from now RISC-V may have the same problem.

Jim

Re: [PATCH] Skip run-readelf-compressed.sh test if built without bzip2

2019-01-13 Thread Mark Wielaard 
On Wed, Jan 09, 2019 at 01:30:19PM +, Ulf Hermann wrote:
> Obviously, we cannot read the compressed ELF file if no bzip2 support is
> present.

Added a ChangeLog and pushed to master.
Please don't sent patches with base64 encoding.
That make it really hard to apply them with git am.

Thanks,

Mark