In article <3cf2e88d-1262-419d-bfcf-c11599e2b...@me.com>,
Jason Thorpe wrote:
>
>> On Jan 5, 2023, at 8:53 AM, Christos Zoulas wrote:
>>
>> Hello,
>>
>> Our dynamic linker ld_elf.so in map_object.c currently can only handle
>2 PT_LOAD segments (one for text and one for data); the kernel elf
Hi!
On Fri, Jan 06, 2023 at 12:51:30AM +0700, Robert Elz wrote:
> In addition, since there is now an option, standard option processing
> is to be required (including support for --) which wasn't actually
> required before (and perhaps technically wasn't even permitted).
It's required, and this
> On Jan 5, 2023, at 8:53 AM, Christos Zoulas wrote:
>
> Hello,
>
> Our dynamic linker ld_elf.so in map_object.c currently can only handle 2
> PT_LOAD segments (one for text and one for data); the kernel elf loader does
> not have this limitation, it can load multiple PT_LOAD segment. The
I am going to attempt to go back to what I was doing a year or
two ago, and note relevant POSIX changes (when they're simply
updating to specify what we already do, or inconsequential changes
that don't really affect anything, I'll ignore those).
One which just seems to have happened:
tsort is
Hello,
Our dynamic linker ld_elf.so in map_object.c currently can only handle 2
PT_LOAD segments (one for text and one for data); the kernel elf loader
does not have this limitation, it can load multiple PT_LOAD segment. The
following patch (from FreeBSD) removes this limitation from the
Date:Thu, 5 Jan 2023 11:16:22 -0500 (EST)
From:Mouse
Message-ID: <202301051616.laa11...@stone.rodents-montreal.org>
Answering your 2 recent messages backwards:
| But I don't understand why the code isn't instead something more
| like
|
| if (! (have &
> Actually, replace that last patch with this one. The previous one
> wouldn't work if begin and end were the same value (intending to get
> just one output value) - though why anyone would write the args that
> way instead of just saying 1 reps begin at ... I cannot imagine.
Perhaps because
Actually, replace that last patch with this one. The previous one
wouldn't work if begin and end were the same value (intending to get
just one output value) - though why anyone would write the args that
way instead of just saying 1 reps begin at ... I cannot imagine.
This patch doesn't have
> As an extra bonus, the appended patch causes jot to generate what
> you're expecting.
True. But I don't understand why the code isn't instead something more
like
if (! (have & REPS)) reps = 100;
if (! (have & BEGIN)) begin = 1;
if (! (have & ENDER)) ender = 100;
>> jot -s "" - 32 126
>> Based on reading the manpage, I would expect that to produce a
>> single line 323334353637...124125126. It does on my 1.4T. On my
>> 5.2, ftp.n.o's 9.0_STABLE, and a work 9.1 machine, the line actually
>> ends ...125126127128129130131.
> The man page actually says:
>
As an extra bonus, the appended patch causes jot to generate what
you're expecting. I'm not going to apply it however, without someone
who knows what jot is really intended to do in this situation indicates
that it is a reasonable thing to have happen (in which case it would also
need a man page
Date:Thu, 5 Jan 2023 09:52:06 -0500 (EST)
From:Mouse
Message-ID: <202301051452.jaa23...@stone.rodents-montreal.org>
| jot -s "" - 32 126
|
| Based on reading the manpage, I would expect that to produce a single
| line 323334353637...124125126. It does on my
jot -s "" - 32 126
Based on reading the manpage, I would expect that to produce a single
line 323334353637...124125126. It does on my 1.4T. On my 5.2,
ftp.n.o's 9.0_STABLE, and a work 9.1 machine, the line actually ends
...125126127128129130131.
Am I misunderstanding how the arguments work, or
13 matches
Mail list logo
