Status Update
Comments
lu...@gmail.com <lu...@gmail.com> #2
an...@google.com <an...@google.com>
an...@google.com <an...@google.com> #3
an...@google.com <an...@google.com> #4
lu...@gmail.com <lu...@gmail.com> #5
lu...@gmail.com <lu...@gmail.com> #6
an...@google.com <an...@google.com> #7
lu...@gmail.com <lu...@gmail.com> #8
When the verifier visits the MDSubprogram entry for function B it finds the instruction originally from A, walks its debug info attachments and finds that it points to function A, and fails verification.
I'm not sure if it matters whether B is ultimately inlined into C or not. It does appear that a workaround is to generate debug info for B.
For glibc-compat this happens because the main program for the unit tests is built without debug info (it's built in one command without a separate link step). So as a workaround you could enable debug info for that. Usually everything has debug info or nothing does (this case can only happen with LTO) but clearly it should work, and it definitely seems to be an upstream bug.
an...@google.com <an...@google.com> #9
sh...@google.com <sh...@google.com> #10 Restricted
an...@google.com <an...@google.com> #11
da...@outlook.com <da...@outlook.com> #12
commit 3e51032a7156a948d03edcc4e4a919ace972becf
Author: Derek Schuff <dschuff@chromium.org>
Date: Wed Jun 24 16:33:19 2015
PNaCl: Update LLVM revision in pnacl/COMPONENT_REVISIONS
This pulls in the following LLVM changes:
44f58b6: (petar.jovanovic@rt-rk.com) [MIPS] Set pnacl-llc arguments for MIPS
74a458c: (petar.jovanovic@rt-rk.com) [MIPS] Force UseReadOnlyJumpTables to true for NaCl subtarget
d62b2e9: (kschimpf@google.com) Fix handling of TYPE_CODE_NUMENTRY record when size large.
9b9fd38: (kschimpf@google.com) Extend the munging bitcode records to generate text records.
3389b3d: (kschimpf@google.com) Modify pnacl-{llc,thaw} to read textual bitcode records.
93d4c96: (kschimpf@google.com) Make function readNaClRecordTextAndBuildBitcode public.
8457aca: (kschimpf@google.com) Fix error category handling in textual bitcode reader.
0606321: (jpp@chromium.org) Subzero. Adds x86-64 to the list of supported Subzero targets.
bf00952: (jpp@chromium.org) Removes x86_64 from ALL_TARGETS.
9ad211b: (dschuff@chromium.org) Stub out DISubprograms that point to functions without dbg attachments
BUG= arguments are wrong for MIPS
BUG=
BUG=
BUG=
BUG=
BUG=
BUG=
TEST= PNaCl toolchain trybots
R=jpp@chromium.org
Review URL:
[modify]
da...@gmail.com <da...@gmail.com> #13
commit 66c300e071cf3e1c1fb98f9a3e15bb02b4388d72
Author: Derek Schuff <dschuff@chromium.org>
Date: Wed Jun 24 20:40:00 2015
Update revision for PNaCl
Update 287c0fffd7d3b7f38b887324f261ddb724d38f26 -> 3e51032a7156a948d03edcc4e4a919ace972becf
Pull the following PNaCl changes into NaCl:
3e51032: (dschuff@chromium.org) PNaCl: Update LLVM revision in pnacl/COMPONENT_REVISIONS
| 44f58b6: (petar.jovanovic@rt-rk.com) [MIPS] Set pnacl-llc arguments for MIPS
| 74a458c: (petar.jovanovic@rt-rk.com) [MIPS] Force UseReadOnlyJumpTables to true for NaCl subtarget
| d62b2e9: (kschimpf@google.com) Fix handling of TYPE_CODE_NUMENTRY record when size large.
| 9b9fd38: (kschimpf@google.com) Extend the munging bitcode records to generate text records.
| 3389b3d: (kschimpf@google.com) Modify pnacl-{llc,thaw} to read textual bitcode records.
| 93d4c96: (kschimpf@google.com) Make function readNaClRecordTextAndBuildBitcode public.
| 8457aca: (kschimpf@google.com) Fix error category handling in textual bitcode reader.
| 0606321: (jpp@chromium.org) Subzero. Adds x86-64 to the list of supported Subzero targets.
| bf00952: (jpp@chromium.org) Removes x86_64 from ALL_TARGETS.
| 9ad211b: (dschuff@chromium.org) Stub out DISubprograms that point to functions without dbg attachments
TBR=jfb@chromium.org
TEST=git cl try
(Please LGTM this change and tick the "commit" box)
BUG=
BUG=
BUG=
BUG=
BUG=
Review URL:
[modify]
[modify]
[modify]
ma...@gmail.com <ma...@gmail.com> #14
je...@gmail.com <je...@gmail.com> #15
hu...@gmail.com <hu...@gmail.com> #16
ni...@gmail.com <ni...@gmail.com> #17
gm...@gmail.com <gm...@gmail.com> #18
he...@gmail.com <he...@gmail.com> #19
ab...@gmail.com <ab...@gmail.com> #20
mo...@gmail.com <mo...@gmail.com> #21
an...@google.com <an...@google.com>
ma...@gmail.com <ma...@gmail.com> #22
[Auto-CCs applied]
[Monorail components: PNaCl]
[Monorail blocked-on:
[Monorail blocking:
ni...@gmail.com <ni...@gmail.com> #23
lf...@gmail.com <lf...@gmail.com> #24
an...@gmail.com <an...@gmail.com> #25
I am glad it got "Assigned" and marked as "Bug"!
cr...@gmail.com <cr...@gmail.com> #26
You are kidding me that this was intentionally removed and will now be only available for the Pixel 8a and beyond?
Pixel 8 Pro user here who loved this feature...
Please revert your change!
to...@gmail.com <to...@gmail.com> #27
sp...@gmail.com <sp...@gmail.com> #28
aa...@gmail.com <aa...@gmail.com> #29
Imagine buying Google's most expensive phone and then seeing software features locked to the budget model of the exact same series of phone. Definitely going to heavily reconsider Google products in the future if this is the way Google is going to approach basic software features.
jo...@gmail.com <jo...@gmail.com> #30
ma...@struzsky.cz <ma...@struzsky.cz> #31
ma...@struzsky.cz <ma...@struzsky.cz> #32
Definitely going to heavily reconsider Google products in the future if this is the way Google is going to approach basic software features.
+1
You really should reconsider how you treat your customers using your phones or your services in general. The only reason I am not using iPhone yet is that I hate their walled garden policy even more, but each and every case of your corporate incompetence really starts to make me think that walled garden might not be as bad as this. My Pixel 6a is great, but it has its issues (dual SIM calls dropping – luckily solved by RMA, inability to tap to wake from time to time, an Android bug known since 2018, I cannot remove obsolete devices from Google Play, reported for many years too, inability to use certain features like Family Link or Google Play rating as a Workspace user etc.).
I love receiving new Android a few hours after it's announced, but maybe it's just not worth it.
Pls do the right thing and bring this one feature back!
ph...@gmail.com <ph...@gmail.com> #33
tb...@gmail.com <tb...@gmail.com> #34
If it wasn't bad enough how buggy this phone is, now you remove features that were a selling point in the first place?
vi...@gmail.com <vi...@gmail.com> #35
Imagine promising 7 years of OS updates and only 2 year old devices getting pretty much nothing new in QPR's and also getting treated like this. Great job Google.
jd...@gmail.com <jd...@gmail.com> #36
de...@gmail.com <de...@gmail.com> #37
ew...@gmail.com <ew...@gmail.com> #38
To respond to a commenter:
now you remove features that were a selling point in the first place?
Just to be clear, a feature like this shouldn't even be called a "selling point." This is a feature that is widely available on other Android and Apple devices, and there are many use cases.
Some examples:
- if you buy a refurbished smartphone, being able to see the battery health information is important since it tells you if your battery is too old or needs to be replaced (in which case you can ask for a warranty exchange). If I buy a refurbished phone, I expect the battery to be at least somewhat usable. If the battery only has 60% estimated capacity, I would get that returned ASAP.
- although not as significant of a reason, if you want to keep my phone for more than 1 year, being able to see your phone's battery health is important because you can decide when the phone's battery should be replaced.
There's no reason why this feature should be limited to the "Pixel 8a and beyond." If you create a full bug report (which can be done through Developer Options), or you use an app that can get ADB access (e.g., aBattery and Shizuku), or you use ADB directly, you can easily get these numbers (battery cycle, estimated capacity remaining, etc.). I'm able to do this on a Pixel 8 Pro (a device that's only 6 months old) and a Pixel 4A (which is stuck on Android 13 because Google no longer supports it). So, in other words, the numbers are clearly there, and they're clearly available.
I could talk more about how this behavior just shows that Google is becoming more anti-consumerism, but I digress.
I do hope that Google changes course and makes battery health information available to all devices with Android 14. Seeing that this bug report has been reassigned, reopened, and labeled as a bug does give me some hope. We'll see what happens in the next feature drop.
ma...@gmail.com <ma...@gmail.com> #39
d....@googlemail.com <d....@googlemail.com> #40
Dear Google Devs, please bring this feature back.
he...@gmail.com <he...@gmail.com> #41
vi...@gmail.com <vi...@gmail.com> #42
ri...@gmail.com <ri...@gmail.com> #43
And Pixel 8 Pro has been promised 7 years of OS update and now they are starting to remove features bits by bits...
Is this another way to stop user of being aware of their battery is degraded and force user to replace phone yearly or every 2 years?
So much of "eco-friendly".
Dear Rick Osterloh, are you aware of this? lol...
vv...@google.com <vv...@google.com> #44
The feedback has been passed on to the product team for consideration.
kr...@janusz.info <kr...@janusz.info> #45
Very poor decision. Google should consider changing marketing to "Your Pixel is getting massively worse with time - Pixel Drops". In either case I think investing any money in hardware made by Google should be reconsidered by users.
ma...@struzsky.cz <ma...@struzsky.cz> #46
Wow, you closed this issue again? I had the battery info on my Pixel 6a, you removed it and stated that it will be available on Pixel 8a and beyond. I now have the Pixel 8A and there is still no battery info. Please re-open this issue and fix it.
ma...@struzsky.cz <ma...@struzsky.cz> #47
Oh, sorry, I have the info on my Pixel 8a, was checking the wrong Settings page. :-) Still sad you removed from older Pixels which already had this, there is no reason why you should do so.
Description
- Build Number: google/lynx_beta/lynx:14/AP11.231117.006/11174680:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
What type of Android issue is this? Battery / Power
When did this happen?
Dec 19, 2023 3:15 PM GMT+01:00
What steps would let us observe this issue?
1. Open settings-about Phone Point battery Info is missing
What did you expect to happen?
See battery info
What actually happened?
Nothing
How often has this happened?
Every time
What was the effect of this issue on your device usage, such as lost time or work?
Slight
Debugging information
Google Play-Dienste
com.google.android.gms
Version 234914038 (23.49.14 (190400-590296185))
System App (Updated)
Android System WebView
com.google.android.webview
Version 609904333 (120.0.6099.43)
System App (Updated)
Network operator:
SIM operator: Vodafone
Filed by Android Beta Feedback. Version (Updated): 2.39-betterbug.external_20231115_RC02 (DOGFOOD)
To learn more about our feedback process, please visit