Replace brk and sbrk with minimal implementations on arm64
AbandonedPublic
Actions

Authored by andrew on Jan 24 2016, 6:46 PM.

Details

Reviewers

kib
brooks

Summary

We no longer need sbrk and brk to do anything useful in the base system, however it is useful for them to still exist as third party software may expect them. As such reduce them to the minimal implementation that sets errno to ENOSYS and returns an error.

As a side effect we can remove the hack for _end from crt1.S.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

andrew updated this revision to Diff 12647.Jan 24 2016, 6:46 PM

andrew retitled this revision from to Replace brk and sbrk with minimal implementations on arm64.

andrew updated this object.

andrew edited the test plan for this revision. (Show Details)

andrew added reviewers: brooks, kib.

andrew set the repository for this revision to rS FreeBSD src repository - subversion.

Herald added subscribers: emaste, imp. · View Herald TranscriptJan 24 2016, 6:46 PM

Note this is not complete as malloc needs to be updated to not use sbrk, but I'm mostly interested in knowing if this is an acceptable change.

I am not sure how to interpret the word 'acceptable' in the review request.

OTOH, I do think that this is definitely an overreaction to the ld(1) bug.

In a lot of ways I'd prefer to kill them entirely and provide a stub implementation in a libbrk in ports. These largely obsolete interfaces are >35 years old and it would be nice not to have to carry them for another 30.

In D5053#107576, @kib wrote:

OTOH, I do think that this is definitely an overreaction to the ld(1) bug.

Me proposing this is unrelated to the _end ld bug, that's just a nice side effect of this change.

In D5053#107808, @andrew wrote:

Me proposing this is unrelated to the _end ld bug, that's just a nice side effect of this change.

Then the question is how popular is sbrk among third-party software. E.g., do third-party malloc(3) implementations all have correct fall back to mmap ?

I cannot say much more right now, but I am also in the process of adding some knob to our imgact infrastructure which would allow mmap(2) to consume data segment, in particular, area between end of .bss and RDATA_LIMIT.

Not needed