https://sourceware.org/bugzilla/show_bug.cgi?id=32274
--- Comment #2 from Sourceware Commits ---
The master branch has been updated by Vladimir Mezentsev
:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d6a07eeabbadbf846da7d6841340fc589d9a57aa
commit d6a07eeabbadbf846da7d6841340fc58
https://sourceware.org/bugzilla/show_bug.cgi?id=32273
--- Comment #2 from Sourceware Commits ---
The master branch has been updated by Vladimir Mezentsev
:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d6a07eeabbadbf846da7d6841340fc589d9a57aa
commit d6a07eeabbadbf846da7d6841340fc58
https://sourceware.org/bugzilla/show_bug.cgi?id=32256
Akhilesh Kumar changed:
What|Removed |Added
Summary|[Bug] internal labels |Observed local symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=32256
--- Comment #4 from Akhilesh Kumar ---
Sharing more update on this
When compiling RISC-V kernel modules with the `-mno-relax` flag, I notice that
local symbols with the `.L` prefix are still generated in the output,
which seems inconsist
https://sourceware.org/bugzilla/show_bug.cgi?id=32254
--- Comment #3 from Nick Clifton ---
(In reply to rdiez-2006 from comment #2)
> > Since the last-modified timestamp on the .info files matches
> > that on the .texi files, the build system thinks that it
> > needs to regenerate all of the doc
https://sourceware.org/bugzilla/show_bug.cgi?id=32260
--- Comment #11 from Sourceware Commits ---
The master branch has been updated by Michael Matz :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ed3228de9b3335e5c97f738fc22d682f56d42316
commit ed3228de9b3335e5c97f738fc22d682f56d42
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #10 from Stas Sergeev ---
Let me clarify.
So with --Trodata-segment=0x08148000 I get this:
ТипСмещ.Вирт.адр Физ.адрРзм.фйл Рзм.пм Флг Выравн
LOAD 0x00 0x08048000 0x08048000 0x0011c 0x0011c
https://sourceware.org/bugzilla/show_bug.cgi?id=32254
--- Comment #2 from rdiez-2006 at rd10 dot de ---
Thanks for your feedback. I'll see if I can find some time to test it over the
weekend.
In the mean time, maybe you can help me understand the following better:
> Since the last-modified times
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #9 from Stas Sergeev ---
(In reply to Nick Clifton from comment #8)
> OK, so the -Ttext-segment sets the start address for the text segment
> and by default the other segments (rodata & data) are mapped to start
> after the end of
https://sourceware.org/bugzilla/show_bug.cgi?id=32254
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #8 from Nick Clifton ---
(In reply to Stas Sergeev from comment #7)
> > My bad. The option is -Ttext-segment=... rather than --text-segment=...
> > Sorry.
>
> Wow!
> This actually works.
> So is it the same as just specifying
>
https://sourceware.org/bugzilla/show_bug.cgi?id=32268
Maciej W. Rozycki changed:
What|Removed |Added
CC||macro at orcam dot me.uk
--
You
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #7 from Stas Sergeev ---
(In reply to Nick Clifton from comment #6)
> (In reply to Stas Sergeev from comment #5)
>
> > Even if it covers some "random"
> > data in a file? IMHO that's still
> > a but. If it would be zero-sized
> >
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #6 from Nick Clifton ---
(In reply to Stas Sergeev from comment #5)
> Even if it covers some "random"
> data in a file? IMHO that's still
> a but. If it would be zero-sized
> then fine. But its not.
Can you provide a small exampl
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #5 from Stas Sergeev ---
(In reply to Nick Clifton from comment #4)
> Sure - if the segment is referencing beyond the of the file then it is a
> bug. But if not then it is more of an unexpected behaviour than a real
> fault.
Even
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #4 from Nick Clifton ---
(In reply to Stas Sergeev from comment #3)
Hi Stas,
>> Agreed, although this is probably an enhancement rather than a bug.
>
> Having stalled PT_LOAD segment
> is most likely a bug. It probably
> refers t
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
--- Comment #3 from Stas Sergeev ---
Thanks for such a detailed reply!
Its really helpful.
(In reply to Nick Clifton from comment #2)
> Agreed, although this is probably an enhancement rather than a bug.
Having stalled PT_LOAD segment
is mos
https://sourceware.org/bugzilla/show_bug.cgi?id=32271
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2
18 matches
Mail list logo
