Re: [PATCH] Fix a number of build problems found on Solaris and NetBSD (was Re: Oh dear. I regret to inform you that commit 0e65dfbaf3a0299e4837216a103c28625d4b4f1d might be unfortunate)

[Kamil Rytarowski <n54@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3322 bytes --]

On 29.05.2019 23:45, Nick Alcock wrote:
> [Do we want to Cc: the gdb buildbot on this? I presume not: dropped from Cc:.]
> 
> On 29 May 2019, Kamil Rytarowski uttered the following:
> 
>> On 29.05.2019 18:33, Nick Alcock wrote:
>>> On 29 May 2019, Rainer Orth stated:
>>>
>>>> Nix <nix@esperi.org.uk> writes:
>>>>> I stripped almost all of these out, but it looks like one single one
>>>>> survived. It is gone now.
>>>>
>>>> Thanks.
>>>
>>> If you'd like to try the entirely unreviewed patch I'm trying out (works
>>> for me on x86_64-pc-linux-gnu, i686-pc-linux-gnu, mingw, Solaris), here
>>> it is:
>>>
>>
>> I wanted to check this patch on NetBSD but it does not apply for me for
>> some reason (I've used the original source of the mail as a patch).
> 
> It is based on commit 9698cf9b1c485edbbeabc9f65bfd0fdef92e3854, for what
> it's worth.
> 
>> Is it safe to use this off64_t define? Won't there be issues with off_t
>> that is 64-bit on NetBSD and 32-bit on some other OSs?
> 
> Unlikely. This definition is only used for platforms that don't have an
> off64_t already, and is only used for the size of ctf_sect_t.offset.
> Platforms on which off_t is 32-bit and without a 64-bit off_t will
> presumably have a 32-bit limit on the size of their binaries, too, so it
> is not a limitation to restrict section offsets to 32-bit.
> 
> (However... we don't *use* the offset field in any case. If we don't
> mind losing things from the ctf_sect_t, we *could* just entirely drop
> that field, and the cts_type and cts_flags as well. None are used since
> the old ELF reading code was dropped.)
> 
> ... yeah, I'll rejig things that way. It's easier. There's no point
> going through portability trouble for a field we're not even *using*.
> 
> ... found an outright bug in the process: we were sometimes failing to
> set the section size when opening associated string and symbol tables.
> Fixed at the same time (it was right next to a line we were removing).
> 
>>                                                        NetBSD uses the
>> libctf stack from FreeBSD/SunOS for DTrace, will that be compatible with
>> this GDB code?
> 
> As previously noted, the formats are incompatible (and will get more so:
> there are a number of huge size reductions that can be made, all of
> which are of course format changes).
> 
> I can, however, add backward-compatibility code to dynamically upgrade
> the old CTF format to the new one at open time, if this seems to be
> useful. (It's not too different from our format v1). I'm just skeptical
> that it *is* useful, since CTF info is mostly found in OS kernels so
> far, and is in a differently-named section.
> 

We build every binary on NetBSD with CTF and it is used by DTrace.
FreeBSD additionally ported mdb from SunOS.

However there is still DWARF available always so it's not a big problem,
at least in the default environment.

> ... new patch (though I'm not sure you'll be able to apply it any more
> than you could apply the last one). Observe lack of dependence on
> off64_t :)
> 
> Still builds on Solaris. :)
> 

After an attempt to apply the patch and manual fixups of rejected chunks
(patch seems to be malformed in the inlined form), gdb builds again on
NetBSD/amd64 8.99.41.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]