[Bug gdb/31152] New: Formalise unintened functionality in version 9.1

[Bug gdb/31152] New: Formalise unintened functionality in version 9.1

[chris_douglas_email at yahoo dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31152

            Bug ID: 31152
           Summary: Formalise unintened functionality in version 9.1
           Product: gdb
           Version: 14.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: chris_douglas_email at yahoo dot com
  Target Milestone: ---

Most of the time (approximately 95%) I use a gdb binary provided by the Linux
distribution I am using. The remainder of the time, I cross compile a source
release for an obscure processor, in order to debug on “bare metal”
(re-purposing old tech so all I have to start with is a Linux kernel and a
terminal of some kind).

The first time I did this I used release 9.1 and cross compiling a static
executable gave me what I needed. This time (after cross compiling glib etc) I
tried the same with version 14.1 and the box restarted indicating a kernel
error. I rebuilt 9.1 and started to debug 14.1 and found it was trying to exec
iconv. A quick hack and it compiled with the dummy iconv used for a win32 build
only to have a segment trap because the ifdef path for linux used a pointer set
up through the exec iconv path.

I have a workaround because I can use version 9.1 (possibly others, I have not
checked) until GCC adopts a version of dwarf this version does not understand,
so I believe this is low priority.

I wish to request an enhancement of a configuration option for “bare metal”
which errors at some point (even compile or link) if more than a linux kernel
is required to run the executable.

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

[Bug gdb/31152] Formalise unintened functionality in version 9.1

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31152

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
On Linux hosts, gdb invokes iconvlist to get the list of
possible charsets.  There's no API for this on Linux.

If you build gdb using GNU libiconv, there will be an API,
and gdb won't try to exec this.

However, you may need additional patching, depending on what
you're trying to do.  For example, on Linux gdb will fork
and then test various ptrace features on its child.  This
is done to detect kernel differences at runtime.

> only to have a segment trap because the ifdef path for linux used a pointer set up through the exec iconv path.

Not sure what's going on here but perhaps whatever you did
was incomplete.  Using libiconv definitely works, even on Linux,
I test this way frequently.  (I don't test the iconv-completely-absent
path.)

Anyway, your needs are relatively unusual.  I'd consider clean patches
to arrange a setup that works for you, but I felt you should know that
it's somewhat unlikely that anyone else will pick up this bug.

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

[Bug gdb/31152] Formalise unintened functionality in version 9.1

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31152

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
Sorry, s/iconvlist/iconv -- iconvlist is the API provided by
libiconv, I got the names crossed.

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

[Bug gdb/31152] Formalise unintened functionality in version 9.1

[chris_douglas_email at yahoo dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31152

--- Comment #3 from stephen douglas <chris_douglas_email at yahoo dot com> ---
Created attachment 15272
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15272&action=edit
Command line output

The version I was able to use was 9.2 i.e. not 9.1 as in the initial report.

The segment trap that was problematic to me was in event-loop.cc. It had
correcly detected that I could not use poll so was attempting to use select.
Unfortunatly macros FD_SET, FD_CLR and FD_ISSET access data outside the data
structure if the file descriptor is NOT less than FD_SETSIZE. The root cause is
that the commercially modified linux kernel that I was attempting to use
encrypts file descriptors, so I was lucky that the encryption did not make the
file descryptor too large on the old version. As stated in earlier comments my
useage is unusual so I would understanf if this was closed, as invalid, without
update for protection against the segment trap.

However, once the segment trap was fixed (by updating glibc so FD_SETSIZE was
larger than the standard value), I did get a warning (see attachment). The
warning is not present in the old version. On "bare metal" build, only built in
conversions are available in iconv i.e. UTF-32BE & UTF-32LE are not available.
However UCS-4BE & UCS-4LE are available. My reading of the 2 sets of
specifications are that they are equivelent. I would alsounderstand if this was
closed with no action on this issue.

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

[Bug gdb/31152] Formalise unintened functionality in version 9.1

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31152

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
I'm curious what you mean by "encrypts file descriptors" -- could you
explain that?

If you have a host that (1) cannot use poll, but also where (2) select
cannot handle the file descriptors handed out by the kernel -- then
indeed this is a tough situation.  I don't understand how many programs
could work, for example any GUI.

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

[Bug gdb/31152] Formalise unintened functionality in version 9.1

[chris_douglas_email at yahoo dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31152

--- Comment #5 from stephen douglas <chris_douglas_email at yahoo dot com> ---
As I stated in my initial post, my hobby is repurposing old tech. I look at the
box as a set of peripherals with a processor in the middle costing a lot less
than the cards for a PC (usually less than 10%). I write to the manufacturer,
and if they consider the box obsolete, they usually tell you what they have
done to prevent “piracy” if you sign an NDA. I then offer to either remove the
comments from anything developed using information in the NDA and then change
meaningful names to gobbledygook (a secure password generator is usually good)
OR publish the .S of the .c. If we are both happy with this I sign the NDA. I
then use gdb to sort out anything I miss. I cleared “encrypted” to describe
what they do to file descriptors but the details are subject to the NDA. I have
an unexplained change in my glibc source to increase the size of the
constant(s) FD_SETSIZE is generated from so it copes.

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

[Bug gdb/31152] Formalise unintened functionality in version 9.1

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31152

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to stephen douglas from comment #5)
> I have an unexplained change in my glibc
> source to increase the size of the constant(s) FD_SETSIZE is generated from
> so it copes.

Ok, but then I don't understand what you meant in comment #3.

Anyway -- could you summarize what changes you might need?

Or better yet, you could try to fix the problems and we could
see if the changes can be put in.

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

[Bug gdb/31152] Formalise unintened functionality in version 9.1

[chris_douglas_email at yahoo dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31152

--- Comment #7 from stephen douglas <chris_douglas_email at yahoo dot com> ---
Created attachment 15275
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15275&action=edit
Unified difference file to detect cause of segment trap in event-loop.cc

This will error before the segment trap I encountered in event-loop.cc and
would have provided me with enough information to prevent it. I have always
used gbd from a cli on the target so don't know if this will prevent a segment
trap if run/gdbserver combination is being used.

If you want to understand, the online manual
https://man7.org/linux/man-pages/man2/select.2.html explains under the heading
BUGS. The file descriptor limitation is in glibc, not the kernel. If the kernel
has not been "tampered with" the condition can not occur.

As stated earlier, my usage is unusual and uncommon. There are other occurances
of the 3 macros that can cause a memmory access outside fd_set with a
"problematic" file descriptor. The macro FD_ZERO uses FD_SETSIZE so can not
access outside fd_set.

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

[Bug gdb/31152] Formalise unintened functionality in version 9.1

[chris_douglas_email at yahoo dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31152

--- Comment #8 from stephen douglas <chris_douglas_email at yahoo dot com> ---
I have tried to create a “simple patch” to fix the warning in comment 3 (as
requested in comment 6). However, there appears to be 3 variants of iconv, the
iconv built from the source of glibc (comments refer to this as gconv), the
iconv provided by libiconv, and use of libintl. I use gconv. I believe someone
with a knowledge of iconv in gdb would stand a better chance. To reproduce the
warning, make the equivalent of
/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache inaccessible. This is not
of any particular concern to me as the fallback processing does everything I
want.

I raised this bug because I believed something had been lost between versions
9.2 and 14.1. I wish to use gdb as a “black box” because it has a deserved
reputation for being “bullet proof”. For it to survive under the initial
conditions, it would need to be “anti-tank missile proof” because the kernels I
am trying to use, in general, reset the box on any error. You have “protection”
(or should I say fixes) for conditions more obscure than the one that caused me
grief. Personally, my current “grey box” knowledge will allow me to have
somewhere to look if I can determine that not getting to the initial
announcement is due to a segment trap, so I no longer “need” a fix.

There are now 2 issues on this bug, I leave it to whoever runs the system if
either are considered valid, and process this bug accordingly.

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